Velocity Reviews > Trap representation

# Trap representation

Richard Tobin
Guest
Posts: n/a

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

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

user923005
Guest
Posts: n/a

 06-22-2007
On Jun 22, 10:51 am, (E-Mail Removed) (Richard Tobin) wrote:
> 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
Guest
Posts: n/a

 06-22-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) (Richard Tobin) writes:
> 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.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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"

Christopher Benson-Manica
Guest
Posts: n/a

 06-22-2007
Richard Tobin <(E-Mail Removed)> wrote:

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

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

Richard Tobin
Guest
Posts: n/a

 06-22-2007
In article <f5h874\$eqj\$(E-Mail Removed)>,
Christopher Benson-Manica <(E-Mail Removed)> wrote:

>> 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?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

user923005
Guest
Posts: n/a

 06-22-2007
On Jun 22, 3:24 pm, (E-Mail Removed) (Richard Tobin) wrote:
> In article <f5h874\$(E-Mail Removed)>,
> Christopher Benson-Manica <(E-Mail Removed)> wrote:
>
> >> 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?

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
"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
Guest
Posts: n/a

 06-22-2007
In article <(E-Mail Removed). com>,
user923005 <(E-Mail Removed)> wrote:

>> 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;

>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

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

CBFalconer
Guest
Posts: n/a

 06-22-2007
Keith Thompson wrote:
> (E-Mail Removed) (Richard Tobin) writes:
>
>> 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.

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

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Keith Thompson
Guest
Posts: n/a

 06-22-2007
(E-Mail Removed) (Richard Tobin) writes:
> In article <(E-Mail Removed). com>,
> user923005 <(E-Mail Removed)> wrote:
>>> 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_Keith) (E-Mail Removed) <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"

Barry Schwarz
Guest
Posts: n/a

 06-22-2007
On 22 Jun 2007 17:51:19 GMT, (E-Mail Removed) (Richard Tobin)
wrote:

>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

Remove del for email