ri*****@cogsci. ed.ac.uk (Richard Tobin) writes:
In article <11************ **********@j4g2 000prf.googlegr oups.com>,
user923005 <dc*****@connx. comwrote:
>> struct foo {int type; char *value;};
struct foo *bar = calloc(1, sizeof(*bar));
[...]
>> struct foo *baz = bar;
then it might be undefined behaviour?
>>No. But accessing an element of baz might, unless you assign
something to it first.
Right, I should have given the example
struct foo baz = *bar;
Yes, that should be ok -- sort of, maybe.
C99 6.2.6.2p6 seems to allow for the possibility that a structure type
can have a trap representation:
When a value is stored in an object of structure or union
type, including in a member object, the bytes of the object
representation that correspond to any padding bytes take
unspecified values. The values of padding bytes shall
not affect whether the value of such an object is a trap
representation. Those bits of a structure or union object that
are in the same byte as a bit-field member, but are not part
of that member, shall similarly not affect whether the value
of such an object is a trap representation.
with a footnote:
Thus, for example, structure assignment may be implemented
element-at-a-time or via memcpy.
But n1124 6.2.6.2p6 is a bit different:
When a value is stored in an object of structure or union
type, including in a member object, the bytes of the object
representation that correspond to any padding bytes take
unspecified values. The value of a structure or union object is
never a trap representation, even though the value of a member
of the structure or union object may be a trap representation.
with a footnote:
Thus, for example, structure assignment need not copy any padding
bits.
So if you have a post-C99 compiler, you'll be just fine. And if you
have just a C99 compiler, or even a C90 compiler, you're *probably*
ok; I suspect the committee made that change because all existing
implementations already work that way. It would have required extra
work to behave differently.
>>On the other hand, calloc() is a total waste of time on anything
besides unsigned char, if you want portable behavior. I seem to
recall a discussion here in c.l.c some time ago that showed anything
besides unsigned char cannot be reliably initialized with calloc().
That would seem to follow from the fact that other integer types can
have padding bits. But footnote 253 under calloc() specifically draws
attention to the fact that it may not produce a null pointer or
floating-point zero, which strongly suggests that the authors of the
standard thought it *was* guaranteed to produce integer zeros.
Perhaps something else insures that all-bits-zero is a legal, zero
int?
This is another post-C99 change. n1124 6.2.6.2p5 says:
For any integer type, the object representation where all the bits
are zero shall be a representation of the value zero in that type.
This sentence does not appear in the original C99 standard. Again, I
think the committee made this change because all existing
implementations already work this way.
Of course, if you're on the DS9K, you'll have to make sure the
documentation actually says it conforms to n1124 (or equivalently to
C99 plus TC1 and TC2).
--
Keith Thompson (The_Other_Keit h)
ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
