[fedora-arm] Broken sha512sum in coreutils

[omalleys at msu.edu]

Quoting Andy Green <andy at warmcat.com>:

> On 01/10/11 16:19, Somebody in the thread at some point said:
>> Quoting Andy Green<andy at warmcat.com>:
>>
>>> On 01/10/11 12:23, Somebody in the thread at some point said:
>>>
>>>>>> Even on x86 it may not always generate code that does what you want:
>>>>>> gcc is perfectly entitled to assume that an unaligned pointer is
>>>>>> never used. And even now, x86 has a big performance hit for word
>>>>>> accesses that straddle a cache line boundary.
>>>>>
>>>>> I don't know about gcc being able to discard unaligned pointers, and
>>>>> have never observed it to my knowledge. That's just a "C lawyer"
>>>>> possibility or actually can happen?
>>>>
>>>> Both. It doesn't happen, but according to the language specification
>>>> it could. However, we've seen quite enough of "this is only a
>>>> language lawyer's theoretical possibility" bugs turning into real
>>>> bugs.
>>>
>>> Well, with --pedantic -Wall -Werror gcc doesn't care to warn about the
>>> unaligned pointer test x.c I posted the other day (not even with a
>>> static byte buffer) and produces code using the pointer correctly.  So I
>>> think you're right with gcc at least silently dropping a misaligned
>>> pointer "doesn't happen" and I still don't know what the basis is that
>>> it could happen.
>>>
>>> I agree though having been bitten by it myself with mIsdn a guy just
>>> casting things unaligned is at least writing nonportable code and should
>>> be able to be written better.  There're benefits even on x86 and ARM
>>> with hardware fixup so it's hard to argue against.
>>
>> I think you will find this interesting.
>>
>> on fc14 i586 gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
>> [so at bk14 ~]$ gcc --pedantic -o x x.c
>> x.c: In function ?main?:
>> x.c:9:2: warning: pointer targets in passing argument 1 of ?strcpy?
>> differ in signedness
>> /usr/include/string.h:128:14: note: expected ?char * __restrict__? but
>> argument is of type ?unsigned char *?
>
> It's just noticing that we passed as unsigned char * when strcpy is  
> built to want a char *, because of pedantic.

only if pedantic is the default flag.. it throws the same error  
without pedantic.


> That's nothing to do with alignment, and if you edit the buffer to  
> be char [] instead of unsigned char [] there are no warnings,  
> despite the alignment problem is still there the same.

Right.

>> Also if you add -Wcast-align gcc version 4.3.2 (Debian 4.3.2-1.1) on
>> the guruplug, you actually get
>> x.c:7: warning: cast increases required alignment of target type
>
> That is interesting... I also can see that if I give -Wcast-align on  
> 4.4.2 on F12 Arm Fedora despite it doesn't appear with -Wall.

On 4.5.1 I can't get it to throw the error with -Wcast-align or any  
other combination of flags I have tried.

> However with this -->
>
> #include <stdio.h>
> #include <string.h>
>
> int main(int argc, char * argv[])
> {
>     char buf[8];
>     void *v = &buf[1];
>     unsigned int *p = (unsigned int *)v;
>
>     strcpy(buf, "abcdefg");
>
>     printf("0x%08x\n", *p);
>
>     return 0;
> }
>
> which is a very common construct that an unknown-typed pointer is  
> passed into a callback API as a void *, but the callback knows its  
> type and casts it, you still don't get any warning even with:
>
> gcc --pedantic -Wall -Werror -Wcast-align /tmp/x.c
>
> So it's not going to sniff out all the problems.  Still, thanks for  
> pointing that out.

4.3.2 and 4.5.1 didnt throw any warnings with this either.

I have seen the void * warnings with SunCC but that throws about 5x  
more warnings as gcc with -Wall anyway.