[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] bug - pointer cast
From: |
Dave Dodge |
Subject: |
Re: [Tinycc-devel] bug - pointer cast |
Date: |
Sat, 23 Jul 2005 07:54:34 -0400 |
User-agent: |
Mutt/1.4.2i |
On Sat, Jul 23, 2005 at 09:30:31AM +0300, Oded Shimon wrote:
> 09:29) address@hidden:~ $ cat -n a.c
> 1 #include <inttypes.h>
> 2 int main(void) {
> 3 uint8_t * a, b[] = { 1, 1, 0, 0 };
> 4 a = b;
> 5 printf("%u\n", *((uint32_t *)&a[0]));
> 6 printf("%u\n", *((uint32_t *)a));
> 7 return 0;
> 8 }
Note that your example code is invoking undefined behavior (besides
the failure to include <stdio.h>). C provides no guarantee that b is
suitably aligned for use as a uint32_t. For example on Sparc/Solaris,
which is much stricter about alignment, simply adding a few more
variables to change the storage layout causes the program to fail:
- uint8_t * a, b[] = { 1, 1, 0, 0 };
+ uint8_t * a, c, d, b[] = { 1, 1, 0, 0 };
$ gcc foo.c && ./a.out
Bus Error
That said, it might still sort of be considered a bug in tcc since
i386 doesn't really require natural alignment of types; you'd
therefore expect certain results even if C won't guarantee them.
> Took me FOREVER to find that this was why my tcc compilation of
> MPlayer was misbehaving...
If MPlayer is doing this sort of cast without being sure that the
cast is a defined operation, then that's a bug in MPlayer.
-Dave Dodge