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]
