Bug#285396: [ARM] wide chars don't work
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 would be better > off as a result. 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. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285396: [ARM] wide chars don't work
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. > 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. (Such an alignment requirement is surely unusal, I suspect it might turn out to be some unintended gcc behaviour.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285396: [ARM] wide chars don't work
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? 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. >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 describes a contiguously allocated nonempty set of objects with a particular member object type, called the element type.31) Array types are characterized by their element type and by the number of elements in the array. An array type is said to be derived from its element type, and if its element type is T, the array type is sometimes called ``array of T''. The construction of an array type from an element type is called ``array type derivation''. -- A structure type describes a sequentially allocated nonempty set of member objects (and, in certain circumstances, an incomplete array), each of which has an optionally specified name and possibly distinct type. About the sizeof operator: [#3] When applied to an operand that has type char, unsigned char, or signed char, (or a qualified version thereof) the result is 1. When applied to an operand that has array type, the result is the total number of bytes in the array.73) When applied to an operand that has structure or union type, the result is the total number of bytes in such an object, including internal and trailing padding. This means internal and trailing padding is part of the object, and each member object of an aggregation has it. (It would be plain insane to define sizeof(struct ...) in dependence of its context.) This, BTW, is the reason why the canonical way to compute the number of elements in an array is: sizeof array / sizeof array[0] Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285396: [ARM] wide chars don't work
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 describes a contiguously allocated
> > nonempty set of objects with a particular member object
> > type, called the element type.31) Array types are
> > characterized by their element type and by the number
> > of elements in the array. An array type is said to be
> > derived from its element type, and if its element type
> > is T, the array type is sometimes called ``array of
> > T''. The construction of an array type from an element
> > type is called ``array type derivation''.
> >
> > -- A structure type describes a sequentially allocated
> > nonempty set of member objects (and, in certain
> > circumstances, an incomplete array), each of which has
> > an optionally specified name and possibly distinct
> > type.
> >
>
> Seems pretty silent on whether an array of structures are packed or not.
The size is an intrinsic property of the object type. Objects can't
legally overlap (outside of unions). A compiler is free to choose a
different actual memory layout, but then it has to hide this fact,
including pointer alignment etc., which means it is normally not done.
("Packed", btw, means "not in ABI layout" in gcc. The standard has no
notion of "packed", except for bitfield storage layout.)
> > About the sizeof operator:
> >
> >[#3] When applied to an operand that has type char, unsigned
> >char, or signed char, (or a qualified version thereof) the
> >result is 1. When applied to an operand that has array
> >type, the result is the total number of bytes in the
> >array.73) When applied to an operand that has structure or
> >union type, the result is the total number of bytes in such
> >an object, including internal and trailing padding.
> >
> > This means internal and trailing padding is part of the object, and
> > each member object of an aggregation has it. (It would be plain insane
> > to define sizeof(struct ...) in dependence of its context.) This, BTW,
> > is the reason why the canonical way to compute the number of elements
> > in an array is:
> >
> > sizeof array / sizeof array[0]
> >
>
> Note that this works consistently whether the object is padded in size
> or or not, in this case, since the array would double in size even as
> the individual structure size doubled.
Exactly. xlib seems to use the sum of the size of the primitives in an
element instead of the size of the first element.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285396: [ARM] wide chars don't work
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 union is the alignment > of the most restrictive element in that struct or union. Before ANSI C > (note, not C99, but the original ANSI C which postdates Xlib), this was the > way C worked. That ANSI C permits more 'flexible' layout is an ABI > incompatible change between K&R and ANSI C. Correct, ANSI C tightened the rules a bit, mostly in order to make C more portable. > We're talking here about a struct containing two chars. On almost every > machine we've seen, save the ARM, this is two bytes. Would a structure > containing an array of two bytes also be padded to four bytes on this > architecture? I would think so. I have, however, no detailed knowledge about the ARM ABIs. Thiemo signature.asc Description: Digital signature
Re: linux-2.4 deprecated
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 kernel does, but no certain). It is not-so-probable, that's why 2.4.27 was provided and kept the default kernel in the installer. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
