[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 4/4] xen/arm: correctly handle an empty array of platform descs.
On Fri, 2013-05-17 at 16:34 +0100, Jan Beulich wrote: > >>> On 17.05.13 at 16:34, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote: > > On Fri, 2013-05-17 at 11:39 +0100, Jan Beulich wrote: > >> >> And btw., for both 32- and 64-bit ARM, other than for x86, I see > >> >> empty structure instances occupy zero bytes (and hence distinct > >> >> symbols end up at the same address), so the compiler is conflicting > >> >> with itself here. > >> > > >> > I imagine this is as much to do with the architecture ABI as the > >> > compiler. > >> > >> So do I, but this doesn't make this any less of a compiler bug. > > > > Is there a requirement (e.g. from the C standard) that an empty struct > > take at least one byte, or more likely I suppose something about > > different instances having different addresses which sort of implies it? > > Yes: "Two pointers compare equal if and only if both are null pointers, > both are pointers to the same object (including a pointer to an object > and a subobject at its beginning) or function, both are pointers to one > past the last element of the same array object, or one is a pointer to > one past the end of one array object and the other is a pointer to the > start of a different array object that happens to immediately follow > the first array object in the address space." Right, that rings a bell, thanks. Even on x86 I see this: struct foo { }; static struct foo a, b; int main(void) { printf("a %p %lx\n", &a, (unsigned long)&a); printf("b %p %lx\n", &b, (unsigned long)&b); printf("a and b are %s\n", &a == &b ? "equal" : "distinct"); printf("ulong a and b are %s\n", (unsigned long)&a == (unsigned long)&b ? "equal" : "distinct"); } $ gcc --version gcc (Debian 4.7.2-5) 4.7.2 $ gcc -O2 t.c $ ./a.out a 0x60094c 60094c b 0x60094c 60094c a and b are distinct ulong a and b are distinct and I see the same thing on arm32 and visibility has no affect. This seems to conform to what you quote above even though the addresses appear equal. I was a bit surprised about the casted result... (I can't quite shake the feeling I've done something stupid here...) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |