[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120613173631.GG163@brightrain.aerifal.cx>
Date: Wed, 13 Jun 2012 13:36:31 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: FreeSec crypt()
On Wed, Jun 13, 2012 at 07:32:48PM +0200, Szabolcs Nagy wrote:
> * Solar Designer <solar@...nwall.com> [2012-06-13 20:45:46 +0400]:
> > On Wed, Jun 13, 2012 at 10:56:03AM -0400, Rich Felker wrote:
> > > Well if char is signed, (char)0x80 << 1 is -256. If char is unsigned,
> > > (char)0x80 << 1 is 256.
> >
> > Sure, but we had:
> >
> > const char *key;
> > u_char *q;
> > *q++ = *key << 1;
> >
> > so while *key << 1 is either -256 or 256 (promoted to int or unsigned
> > int), those high bits get dropped on the assignment to *q anyway,
> > resulting in the same value there either way. No?
>
> yes the code happens to work whenever -128<<1 is -256
>
> and i assume -256 is what most compilers will give
> usually in case of two's complement int representation
>
> but -128<<1 is UB and should be fixed anyway
Note that x<<1 is always equal to x*2 when both are defined, and the
latter is defined in our case since the range of x is much smaller
than half the range of int. So if the underlying pointer type issue
isn't fixed, just changing <<1 to *2 would work.
In general, portable code wanting to use x<<n with negative values of
x could replace it with x*(1<<n) and hope the compiler is smart enough
to generate code equivalent to the traditional behavior of x<<n (i.e.
hope it can apply the associativity to * and <<).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
