Re: [libiberty] problem with unaligned pointers when using md5_process_bytes

[Pierre Vittet <piervit at pvittet dot com>]

>>
>> #if !_STRING_ARCH_unaligned
>> /* To check alignment gcc has an appropriate operator.  Other
>>    compilers don't.  */
>> # if __GNUC__ >= 2
>> #  define UNALIGNED_P(p) (((md5_uintptr) p) % __alignof__ (md5_uint32) 
>> != 0)
>> # else
>> #  define UNALIGNED_P(p) (((md5_uintptr) p) % sizeof (md5_uint32) != 
>> 0)
>> # endif
>> 	len --;
> 
> 
> Where did this ' len --;' come from, it is not in my code.  Maybe that
> is where you are getting unaligned.
Sorry, it is an error from me when I copied, as I could not debug the
macro, I added a line a len ++ in the conditionnal preprocessor branch
to see what was defined, and then a len -- to get normal size back, I
forgot to clean the len --. That does not change the problem.
> 
> 
>>       if (UNALIGNED_P (buffer))
>>         while (len > 64)
>>           {
>> 			memcpy (ctx->buffer, buffer, 64);
>>             md5_process_block (ctx->buffer, 64, ctx);
>>             buffer = (const char *) buffer + 64;
>>             len -= 64;
>>           }
>>       else
>> #endif
>>       md5_process_block (buffer, len & ~63, ctx);
>>       buffer = (const void *) ((const char *) buffer + (len & ~63));
>>       len &= 63;
>>     }

>> I was able to fully compile GCC MELT branch by only adding a pair of 
>> braces as you can see on the given diff file. I guess this is a bug in 
>> libiberty (even if I can't understand why my pointer is not aligned).

> 
> It certainly seems to me that those last three lines should be in a
> single block so they are all controlled by the else clause.  Though I
> also wonder if anyone ever defines _STRING_ARCH_unaligned.  It doesn't
> happen anywhere in configure so I guess the only way it would get
> defined is by a user via CFLAGS.  I wonder if this #if is even needed,
> then we could make the code cleaner by not having an partially ifdef'ed
> if/else statement.
Thanks, I will propose a patch on gcc-patches.

Pierre Vittet
> 
> Steve Ellcey
> sje@cup.hp.com
> 
> 
>