On 10/24/13, John Regehr <regehr_at_[hidden]> wrote:
>>> Well, my guess is that Unisys has already been forced to implement
>>> two's complement signed shifts since the alternative would almost
>>> certainly break shifty applications like crpyto.
>>
>> What reason do you have to believe that crypto is using any signed
>> arithmetic? I would not.
>
> Challenge accepted. Below are the errors from a "make test" of
> today's OpenSSL snapshot using clang -fsanitize=undefined.
>
> $ grep 'runtime error' test.out | sort | uniq | grep -v misalign

Stripping to a single example each...

> a_int.c:397:4: runtime error: left shift of 46242800822734955 by 8
> places cannot be represented in type 'long'
> gost89.c:123:48: runtime error: left shift of 173 by 24 places cannot be
> represented in type 'int'

Okay, they appear to be using a signed shift. Were any of these shifts
of a constant? I ask because 3 << 7 looks unsigned but is not. (IMHO,
a failure in the definition of C, but not one we can fix except through
optional diagnostics.)

Of course, that they are using signed shifts does not mean they intended
to or should be using signed shifts.

> c_enc.c:107:6: runtime error: shift exponent 32 is too large for 32-bit
> type 'unsigned int'
...
> c_enc.c:88:6: runtime error: shift exponent 32 is too large for 32-bit
> type 'unsigned int'

These are a genuine portability problem, but not related to signedness.

> eng_table.c:349:2: runtime error: member access within null pointer of
> type 'ENGINE_TABLE' (aka 'struct st_engine_table')
> s3_srvr.c:1886:13: runtime error: index 4 out of bounds for type
> 'BIGNUM *[4]'

These are just plain broken.

-- 
Lawrence Crowl