473,573 Members | 4,147 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Trap representation

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.
Jun 22 '07 #1
10 3002
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
Jun 22 '07 #2
ri*****@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) 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"
Jun 22 '07 #3
Richard Tobin <ri*****@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.
Jun 22 '07 #4
In article <f5**********@c hessie.cirr.com >,
Christopher Benson-Manica <at***@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.
Jun 22 '07 #5
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().

Jun 22 '07 #6
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;
>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.
Jun 22 '07 #7
Keith Thompson wrote:
ri*****@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

Jun 22 '07 #8
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"
Jun 22 '07 #9
On 22 Jun 2007 17:51:19 GMT, ri*****@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
Jun 22 '07 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

11
437
by: pemo | last post by:
Ambiguous? I have a student who's asked me to explain the following std text (esp. the footnote). 6.2.6.1.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
2
339
by: ramu | last post by:
Hi, I read the phrase " trap representation" in the topic "Union arrangement" in this group. Can you please tell me what do you mean by it? regards
10
2343
by: pemo | last post by:
As far as I understand it, a trap representation means something like - an uninitialised automatic variable might /implicitly/ hold a bit-pattern that, if read, *might* cause a 'trap' (I'm not sure what 'a trap' means here - anyone?). I also read into this that, an *initialised* automatic variable, may never hold a bit pattern that...
6
2496
by: temper3243 | last post by:
Hi Can someone explain me what is happening below ? Why is it printing 401380 $ cat scanf.c #include<stdio.h> int main() { int i; scanf(" %d",&i);
17
1640
by: Army1987 | last post by:
If uMyInt_t is an unsigned integral type, is the following a necessary and sufficient condition that uMyInt_t has no trap representation? (uMyInt_t)(-1) >CHAR_BIT*sizeof(uMyInt_t)-1 That is, I'm asking wheter it equals 0 whenever uMyInt_t has trap representations, equals a nonzero value whenever uMyInt_t has no trap representation, and...
6
2314
by: Army1987 | last post by:
Reliable sources (whose names I'm not allowed to disclose) told me that on the next version of the Deathstation (version 10000, or DS10K) an integral type (they didn't tell which) will have a odd parity bit, that is a bit which is set if an even number of value/sign bits are set, and unset otherwise. If the parity is wrong, the representation...
0
7789
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
8037
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
8215
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
0
8086
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
1
5605
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5296
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3743
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
1325
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
1048
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.