Trap representation

Discussion in 'C Programming' started by Richard Tobin, Jun 22, 2007.

  1. 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.
     
    Richard Tobin, Jun 22, 2007
    #1
    1. Advertising

  2. Richard Tobin

    user923005 Guest

    On Jun 22, 10:51 am, (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
     
    user923005, Jun 22, 2007
    #2
    1. Advertising

  3. (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) <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"
     
    Keith Thompson, Jun 22, 2007
    #3
  4. Richard Tobin <> 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.
     
    Christopher Benson-Manica, Jun 22, 2007
    #4
  5. In article <f5h874$eqj$>,
    Christopher Benson-Manica <> 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.
     
    Richard Tobin, Jun 22, 2007
    #5
  6. Richard Tobin

    user923005 Guest

    On Jun 22, 3:24 pm, (Richard Tobin) wrote:
    > In article <f5h874$>,
    > Christopher Benson-Manica <> 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
    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().
     
    user923005, Jun 22, 2007
    #6
  7. In article <>,
    user923005 <> 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.
     
    Richard Tobin, Jun 23, 2007
    #7
  8. Richard Tobin

    CBFalconer Guest

    Keith Thompson wrote:
    > (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
     
    CBFalconer, Jun 23, 2007
    #8
  9. (Richard Tobin) writes:
    > In article <>,
    > user923005 <> 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) <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"
     
    Keith Thompson, Jun 23, 2007
    #9
  10. On 22 Jun 2007 17:51:19 GMT, (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
     
    Barry Schwarz, Jun 23, 2007
    #10
  11. CBFalconer <> writes:
    > Keith Thompson wrote:
    >> (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_Keith) <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"
     
    Keith Thompson, Jun 23, 2007
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mantorok Redgormor

    trap representation

    Mantorok Redgormor, Sep 11, 2003, in forum: C Programming
    Replies:
    18
    Views:
    711
  2. pemo

    trap representation

    pemo, Dec 5, 2005, in forum: C Programming
    Replies:
    11
    Views:
    538
    Tim Rentsch
    Dec 14, 2005
  3. ramu

    Trap representation

    ramu, Jan 31, 2006, in forum: C Programming
    Replies:
    2
    Views:
    340
    CBFalconer
    Jan 31, 2006
  4. trap representation

    , Jan 12, 2007, in forum: C Programming
    Replies:
    6
    Views:
    1,601
  5. Army1987
    Replies:
    6
    Views:
    339
    CBFalconer
    Jul 7, 2007
Loading...

Share This Page