[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#285396: [ARM] wide chars don't work

Jim Gettys wrote:
> > >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.


Reply to: