Two standards problems

Doug Gwyn gwyn at smoke.BRL.MIL
Sun Aug 13 12:43:00 AEST 1989


In article <186 at ixi.UUCP> clive at ixi.uucp (Clive Feather) writes:
->    typedef
->    {     
->        t_all all;
->    }
->    t_whole;

Note: you're missing "struct" in these typedefs.

->(Q8)  Do the names of the common initial fields of t_all and t_first have to
->      be the same for this to work, or is it sufficient for the types to be
->      identical ?

Member types must match.  Member names don't matter.

->(Q9)  It seems to me that, since the union might only appear in one source
->      file, whilst the structures might be used in several, that the padding
->      of a structure depend *only* on the types of the fields of the
->      structure. Is this so ? If so, how do I get X3J11 to mandate it.

I don't understand the question.  I think you're asking how clever a compiler
is allowed to be with regard to struct padding.  The answer is, it must be
consistent across translation units with regard to the "common initial
members" requirement.

->(Q10) Do all the t_n_parts types have the same alignment requirements ? For
->      historical reasons, there are many functions which take an argument of
->      type t_1_parts, which is actually a value of one of the other types cast
->      correctly. These functions only access the part_1 fields.

The alignment of the t_n_part structure shouldn't matter, since you're using
a pointer to it and no padding is allowed at the beginning of a struct.  The
"common initial members" requirement does the rest of what you seem to need.

->(Q11) Can offsetof take "field1.field2" as its second argument ?

This doesn't seem to have been the intent of Standard section 4.1.5.

->(Q12) If not, can I add the offset of the sub-structure in the main one
->      and the field in the substructure to get the right effect ?
->      (I.e. can I use offsetof (T, field1) + offsetof (SUBT, field2)
->      to get the effect of offsetof (T, field1.field2).

Yes.

->(Q13) Does ANSI guarantee that, given the assertions in the various comments,
->      the call to memcpy will do the assignment ?

No, you're not allowed to perform pointer arithmetic on void*s.

->(Q14) If not, how do I write the last part of GetValue ?

Change your void*s to char*s.



More information about the Comp.std.c mailing list