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
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[user923005]

Re: Trap representation

On Jun 22, 10:51 am, rich...@cogsci. ed.ac.uk (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]

Re: Trap representation

richard@cogsci. ed.ac.uk (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_Keit h) kst-u@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"

[Christopher Benson-Manica]

Re: Trap representation

Richard Tobin <richard@cogsci .ed.ac.ukwrote:

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)gma il.com | don't, I need to know. Flames welcome.

[Richard Tobin]

Re: Trap representation

In article <f5h874$eqj$1@c hessie.cirr.com >,
Christopher Benson-Manica <ataru@faeroes. freeshell.orgwr ote:

>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
>representati on 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
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[user923005]

Re: Trap representation

On Jun 22, 3:24 pm, rich...@cogsci. ed.ac.uk (Richard Tobin) wrote:

In article <f5h874$eq...@c hessie.cirr.com >,
Christopher Benson-Manica <a...@faeroes.f reeshell.orgwro te:
>

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

Re: Trap representation

In article <1182552812.810 870.167910@j4g2 000prf.googlegr oups.com>,
user923005 <dcorbit@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;

>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

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

[CBFalconer]

Re: Trap representation

Keith Thompson wrote:

richard@cogsci. ed.ac.uk (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.securityfoc us.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]

Re: Trap representation

richard@cogsci. ed.ac.uk (Richard Tobin) writes:

In article <1182552812.810 870.167910@j4g2 000prf.googlegr oups.com>,
user923005 <dcorbit@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) kst-u@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"

[Barry Schwarz]

Re: Trap representation

On 22 Jun 2007 17:51:19 GMT, richard@cogsci. ed.ac.uk (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
your program.


Remove del for email

[Keith Thompson]

Re: Trap representation

CBFalconer <cbfalconer@yah oo.comwrites:

Keith Thompson wrote:

>richard@cogsci. ed.ac.uk (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.

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.

--
Keith Thompson (The_Other_Keit h) kst-u@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"