Jim Gettys wrote:
[snip]
> This isn't saying we wouldn't add such a patch to X, though patches for
> a particular compiler on a particular architecture do get frowned on
> quite a lot: I just suspect ARM would find more code "just worked" if
> GCC behaved like other compilers in this case, and ARM
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 ins
Jim Gettys wrote:
[snip]
> > 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
Jim Gettys wrote:
[snip]
> > >From a slightly outdated C99 draft, about the definition of arrays
> > and structures:
> >
> >[#19] Any number of derived types can be constructed from
> >the object, function, and incomplete types, as follows:
> >
> > -- An array type
Keith Packard wrote:
>
> Around 23 o'clock on Jan 11, Thiemo Seufer wrote:
>
> > Exactly. xlib seems to use the sum of the size of the primitives in an
> > element instead of the size of the first element.
>
> No, Xlib assumes that the alignment of the struct or
On Fri, Apr 07, 2006 at 09:38:27AM -0500, Bill Allombert wrote:
[snip]
> Since sarge carry 2.6.8 kernels we could add to the release note to first
> upgrade the kernel to 2.6.8 before the upgrade, but that assume the
> sarge 2.6 kernel will handle their hardware (which is probable if sarge
> 2.4.27
6 matches
Mail list logo
