Trap representation

[Richard Tobin]

May all-bits-zero be a trap representation for a pointer? What if I
calloc() space for a structure containing pointers?

-- Richard

 

[user923005]

May all-bits-zero be a trap representation for a pointer? What if I
calloc() space for a structure containing pointers?

If you never set them to NULL or a defined value before you use them,
I would say that it is possible for undefined behavior to occur.
However, the calloc() itself would not cause undefined behavior. It
would only {theoretially} occur when you accessed the pointers.

©ISO/IEC ISO/IEC 9899:1999 (E)
"7.20.3.1 The calloc function
Synopsis
1 #include <stdlib.h>
void *calloc(size_t nmemb, size_t size);
Description
2 The calloc function allocates space for an array of nmemb objects,
each of whose size is size. The space is initialized to all bits zero.
252)
Returns
3 The calloc function returns either a null pointer or a pointer to
the allocated space.
252) Note that this need not be the same as the representation of
floating-point zero or a null pointer constant."
312 Library §7.20.3.2

"5 Certain object representations need not represent a value of the
object type. If the stored value of an object has such a
representation and is read by an lvalue expression that does not have
character type, the behavior is undefined. If such a representation is
produced by a side effect that modifies all or any part of the object
by an lvalue expression that does not have character type, the
behavior is undefined.41) Such a representation is called a trap
representation.
41) Thus, an automatic variable can be initialized to a trap
representation without causing undefined behavior, but the value of
the variable cannot be used until a proper value is stored in it."
§6.2.6.1 Language 37

 

[Keith Thompson]

May all-bits-zero be a trap representation for a pointer?
Yes.

What if I calloc() space for a structure containing pointers?

Don't do that.

 

[Christopher Benson-Manica]

May all-bits-zero be a trap representation for a pointer? What if I
calloc() space for a structure containing pointers?

The answer seems to be a definite yes. 7.20.3.1, p2, states that "The
space is initialized [by calloc] to all bits zero", with the
(informative?) footnote "Note that this need not be the same as the
representation of floating-point zero or a null pointer constant".
The normative (?) text from which that conclusion derives is contained in
6.2.6.1. p1 states "The representations of all types are unspecified
except as stated in this subclause," and at no time does the word
"pointer" appear in the remainder of the subclause. I would not
expect calloc() to correctly initialize a structure containing
pointers on the DS9K, although of course MMV on real implementations.

 

[Richard Tobin]

May all-bits-zero be a trap representation for a pointer? What if I
calloc() space for a structure containing pointers?

[/QUOTE]

The answer seems to be a definite yes. 7.20.3.1, p2, states that "The
space is initialized [by calloc] to all bits zero", with the
(informative?) footnote "Note that this need not be the same as the
representation of floating-point zero or a null pointer constant".
The normative (?) text from which that conclusion derives is contained in
6.2.6.1. p1 states "The representations of all types are unspecified
except as stated in this subclause," and at no time does the word
"pointer" appear in the remainder of the subclause. I would not
expect calloc() to correctly initialize a structure containing
pointers on the DS9K, although of course MMV on real implementations.

Just to be clear: I have no doubt that calloc() cannot be relied upon
to set pointers to null. I had previously assumed that it was OK to
use calloc() on structs containing pointers provided that I didn't use
the pointers without assigning other values to them first. What I am
asking is whether it is possible for merely calling calloc() and
assigning the result to a struct pointer to invoke undefined behaviour
if the struct contains a pointer.

For example, does the following cause undefined behaviour if
all-bits-null is a trap representation for pointers (as it no doubt is
on the DS9K):

struct foo {int type; char *value;};
struct foo *bar = calloc(1, sizeof(*bar));

Rereading the standard, I see that a trap representation only causes
undefined behaviour if it is "read by an lvalue expression that does
not have character type", or if such a representation is "produced by
a side effect that modifies ... the object by an lvalue expression
that does not have character type". Presumably that does not happen
in the case of calloc(). But if I then do

struct foo *baz = bar;

then it might be undefined behaviour?


-- Richard

 

[user923005]

May all-bits-zero be a trap representation for a pointer? What if I
calloc() space for a structure containing pointers?

The answer seems to be a definite yes. 7.20.3.1, p2, states that "The
space is initialized [by calloc] to all bits zero", with the
(informative?) footnote "Note that this need not be the same as the
representation of floating-point zero or a null pointer constant".
The normative (?) text from which that conclusion derives is contained in
6.2.6.1. p1 states "The representations of all types are unspecified
except as stated in this subclause," and at no time does the word
"pointer" appear in the remainder of the subclause. I would not
expect calloc() to correctly initialize a structure containing
pointers on the DS9K, although of course MMV on real implementations.

Just to be clear: I have no doubt that calloc() cannot be relied upon
to set pointers to null. I had previously assumed that it was OK to
use calloc() on structs containing pointers provided that I didn't use
the pointers without assigning other values to them first. What I am
asking is whether it is possible for merely calling calloc() and
assigning the result to a struct pointer to invoke undefined behaviour
if the struct contains a pointer.

For example, does the following cause undefined behaviour if
all-bits-null is a trap representation for pointers (as it no doubt is
on the DS9K):

struct foo {int type; char *value;};
struct foo *bar = calloc(1, sizeof(*bar));

Rereading the standard, I see that a trap representation only causes
undefined behaviour if it is "read by an lvalue expression that does
not have character type", or if such a representation is "produced by
a side effect that modifies ... the object by an lvalue expression
that does not have character type". Presumably that does not happen
in the case of calloc(). But if I then do

struct foo *baz = bar;

then it might be undefined behaviour?[/QUOTE]

No. But accessing an element of baz might, unless you assign
something to it first.

Consider footnote 41) quoted from the C Standard up above in the
thread:
"41) Thus, an automatic variable can be initialized to a trap
representation without causing undefined behavior, but the value of
the variable cannot be used until a proper value is stored in it."

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().

 

[Richard Tobin]

struct foo {int type; char *value;};
struct foo *bar = calloc(1, sizeof(*bar));

[...]

struct foo *baz = bar;

then it might be undefined behaviour?

[/QUOTE]

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;

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?

-- Richard

 

[CBFalconer]

Don't do that.

By which Keith means use malloc, not calloc. Then initialize.

 

[Keith Thompson]

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.

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).

 

[Barry Schwarz]

May all-bits-zero be a trap representation for a pointer? What if I
Yes.

calloc() space for a structure containing pointers?

All bytes in the allocated memory will be set to all bits zero. This
will not cause any problems unless you attempt to evaluate a portion
of this memory as a pointer before you assign a valid value to that
portion of memory. If all bits zero happens to be the representation
of a NULL pointer on your system, then the value of the pointer is
already valid. If all bits zero happens to be a valid pointer value
but does not represent a valid value in the memory space of your
program, evaluating that value will probably invoke undefined
behavior. If all bits zero is not a valid pointer value, then
evaluating the value will also probably invoke undefined behavior.

There are systems where simply evaluating an address you don't have
access to (not accessing the data at that address) raises a hardware
error condition that normally causes the operating system to interrupt
your program.


Remove del for email

 

[Keith Thompson]

By which Keith means use malloc, not calloc. Then initialize.

Yes, but what Richard is *actually* trying to do (calloc, then
initialize) is ok. calloc will almost certainly properly initialize
all integer members; as long as he doesn't attempt to use the values
of any pointer or floating-point members before assigning values to
them, he should be ok.

I still probably wouldn't use calloc myself, though.