Quoting Andy Green <andy(a)warmcat.com>:
On 01/10/11 16:19, Somebody in the thread at some point said:
> Quoting Andy Green<andy(a)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@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.