On Tue, 2005-01-11 at 21:36 +0100, Thiemo Seufer wrote: > Jim Gettys wrote: > [snip] > > > Well, and deliberate ABI changes are frowned upon by toolchain people. > > > To me (without having looked further than the bug report) this seems to > > > be an implementation bug in xlib, which appears to assume some magic > > > number as element granularity in the array instead of the proper > > > sizeof(element). So the correct fix for it wouldn't be > > > architecture-dependent. > > > > Depends on your point of view. > > I don't think so. xlib makes assumptions which aren't guaranteed by C, > this should IMHO be fixed regardless of the ARM situation.
I wrote that header file was written before there was a C standard; to my knowledge, this is the first instance of this behavior I've seen. (That data structure was added somewhere around 1986 or 1987, IIRC). > > > One point of view is that the current ARM definition is different than > > every other platform, and should be fixed. > > Strictly speaking, the ARM impementation of gcc is allowed to behave > that way by the C standard. Not exercising this degree of freedom may > be desireable to keep broken code working, but I'll leave it to the > ARM people to weigh the tradeoff. Are you sure? Remember it is an array of such structures, not a structure embedded in another structure or on its own.... If you have a pointer to the language in the standard, it might elucidate the situation a bit. > > (Such an alignment requirement is surely unusal, I suspect it might > turn out to be some unintended gcc behaviour.) > As a mostly former ARM person (having worked on the iPAQ handheld extensively), I know my vote.... It isn't clear there is an upward/downward compatible "fix" for this situation; I hate ifdef's in header files... - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]