Value of uninitialized variable

Discussion in 'C Programming' started by Philipp Klaus Krause, Jan 19, 2010.

  1. What's the value of an uninitialized variable?

    E.g. for a bool, is it always true or false? For an int is it an integer
    value in [INT_MIN, INT_MAX]?

    Philipp
     
    Philipp Klaus Krause, Jan 19, 2010
    #1
    1. Advertising

  2. In article <4b5591e6$0$9752$>,
    Philipp Klaus Krause <> wrote:
    >What's the value of an uninitialized variable?


    Not much. Maybe 50 cents on the open market.
     
    Kenny McCormack, Jan 19, 2010
    #2
    1. Advertising

  3. On 19 Jan, 11:05, Philipp Klaus Krause <> wrote:

    > What's the value of an uninitialized variable?


    assuming you're talking about automatic variables (see Richard's post)
    then the value is undefined. The standard allows "trap values" and
    attempts to read a trap value will cause the program to fail.

    > E.g. for a bool, is it always true or false?


    no.

    > For an int is it an integer value in [INT_MIN, INT_MAX]?


    no

    but if it makes you any happier unsigned char is an exception in that
    it cannot be a trap value. I'm guessing that all bit patterns are
    hence valid values.
     
    Nick Keighley, Jan 19, 2010
    #3
  4. In article <>, Nick Keighley <> writes:
    > On 19 Jan, 11:05, Philipp Klaus Krause <> wrote:
    >
    >> What's the value of an uninitialized variable?

    >
    > assuming you're talking about automatic variables (see Richard's post)
    > then the value is undefined. The standard allows "trap values" and
    > attempts to read a trap value will cause the program to fail.


    The derivation seems to be:


    C99 6.7.8 Initialization, p10: "If an object that has automatic storage
    duration is not initialized explicitly, its value is indeterminate."

    C99 3.17.2 "indeterminate value: either an unspecified value or a trap
    representation"

    C99 6.2.6 Representations of types / 6.2.6.1 General, p5

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

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


    For C90, the path is a bit different:

    C90 6.5.7 Initialization

    "If an object that has automatic storage duration is not initialized
    explicitly, its value is indetelminate."

    C90 3.16 "undefined behavior: Behavior, upon use of [...] indeterminately
    valued objects, for which this International Standard imposes no
    requirements."

    I'm not sure if in C90 an access with character type is exempted like in
    C99.

    Cheers,
    lacos
     
    Ersek, Laszlo, Jan 19, 2010
    #4
  5. Philipp Klaus Krause

    Seebs Guest

    On 2010-01-19, Philipp Klaus Krause <> wrote:
    > What's the value of an uninitialized variable?


    Unspecified.

    > E.g. for a bool, is it always true or false? For an int is it an integer
    > value in [INT_MIN, INT_MAX]?


    For anything but unsigned char, it may be a trap representation, which is
    to say, accessing the value can cause undefined behavior.

    (Actually, I'm not sure about bool.)

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Jan 19, 2010
    #5
  6. Philipp Klaus Krause

    Eric Sosman Guest

    On 1/19/2010 12:20 PM, Datesfat Chicks wrote:
    > [...]
    > Usually, the value of an automatic variable, unless it is a pointer and
    > you dereference it, is something that is simply a pseudo-random data
    > value and it won't do any harm to simply access the value or output it
    > using printf(). The reason for this is that in any machine
    > representation, typically all possible bit patterns mean SOMETHING.


    One such SOMETHING is "signalling NaN," for most systems.

    > [...]
    > I believe that some coding standards require initializers on all
    > automatics. The cost in extra code may be justified by the reduction in
    > the probability of a certain class of bug.


    There may well be such standards. IMHO they are wrong-
    headed, ill-advised, counter-productive, and in poor taste.
    Compilers and lints can do enough analysis to tell whether a
    path exists that might cause a variable to be read before it
    is written, and will issue warning messages if such paths
    are found. But if the variable is initialized the diagnostics
    are suppressed, and all you get is a wrong answer at run-time.
    A reproducible wrong answer, yes, and that's helpful in finding
    the bug -- but it's less helpful than having the bug pointed
    out to you at compile time.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 19, 2010
    #6
  7. Philipp Klaus Krause

    Tim Rentsch Guest

    Nick Keighley <> writes:

    > On 19 Jan, 11:05, Philipp Klaus Krause <> wrote:
    >
    >> What's the value of an uninitialized variable?

    >
    > assuming you're talking about automatic variables (see Richard's post)
    > then the value is undefined. The standard allows "trap values" and
    > attempts to read a trap value will cause the program to fail.
    >
    >> E.g. for a bool, is it always true or false?

    >
    > no.
    >
    >> For an int is it an integer value in [INT_MIN, INT_MAX]?

    >
    > no
    >
    > but if it makes you any happier unsigned char is an exception in that
    > it cannot be a trap value. I'm guessing that all bit patterns are
    > hence valid values.


    Under C1X, even unsigned chars can cause traps if unitialized.
    (And there are even real machines that do, which is why the
    behavior was changed.)
     
    Tim Rentsch, Jan 19, 2010
    #7
  8. Seebs <> writes:

    > On 2010-01-19, Philipp Klaus Krause <> wrote:
    >> What's the value of an uninitialized variable?

    >
    > Unspecified.
    >
    >> E.g. for a bool, is it always true or false? For an int is it an integer
    >> value in [INT_MIN, INT_MAX]?

    >
    > For anything but unsigned char, it may be a trap representation, which is
    > to say, accessing the value can cause undefined behavior.
    >
    > (Actually, I'm not sure about bool.)


    I can't see any wording that might exempt _Bool from having trap
    reps. That's not a proof, of course, but where do your doubts come
    from?

    --
    Ben.
     
    Ben Bacarisse, Jan 19, 2010
    #8
  9. Philipp Klaus Krause

    Seebs Guest

    On 2010-01-19, Ben Bacarisse <> wrote:
    > I can't see any wording that might exempt _Bool from having trap
    > reps. That's not a proof, of course, but where do your doubts come
    > from?


    Imagine if you will a _Bool bitfield (I *think* those got officially
    tacked on at some point?) with only one bit. We know it holds two
    values. We know it has two valid values. I don't think it can have
    a trap representation.

    In practice, though, I don't see any guarantees, and a non-bitfield
    _Bool could presumably have as a trap representation "anything but 0 or
    1". Thus, if you assigned 23 to it, the compiler would generate code
    to change that silently to a 1 (because true is always exactly 1),
    but if you memcpy'd 23 over it, it would be a trap representation.

    This would most likely require extra code to set up in the compiler, but
    it might be sorta cool. Certainly, it would lead to another generation of
    insanely complicated #defines for "true".

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Jan 19, 2010
    #9
  10. Seebs <> writes:

    > On 2010-01-19, Ben Bacarisse <> wrote:
    >> I can't see any wording that might exempt _Bool from having trap
    >> reps. That's not a proof, of course, but where do your doubts come
    >> from?

    >
    > Imagine if you will a _Bool bitfield (I *think* those got officially
    > tacked on at some point?) with only one bit. We know it holds two
    > values. We know it has two valid values. I don't think it can have
    > a trap representation.


    I am getting lost. That's an argument that bools with only one bit
    can't have trap reps. I agree. You seemed unwilling to assert that
    bool can have trap reps. Maybe I miss-understood your "I am not sure
    about bool". You've snipped it, so the context is getting lost.

    > In practice, though, I don't see any guarantees, and a non-bitfield
    > _Bool could presumably have as a trap representation "anything but 0 or
    > 1". Thus, if you assigned 23 to it, the compiler would generate code
    > to change that silently to a 1 (because true is always exactly 1),
    > but if you memcpy'd 23 over it, it would be a trap representation.


    Yes, this seems eminently possible. I thought you were not sure that
    this was possible.

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Jan 19, 2010
    #10
  11. Philipp Klaus Krause

    Seebs Guest

    On 2010-01-19, Ben Bacarisse <> wrote:
    > Yes, this seems eminently possible. I thought you were not sure that
    > this was possible.


    I'm not. There could be something I haven't thought of that prevents _Bool
    from being allowed to have a trap representation.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
     
    Seebs, Jan 20, 2010
    #11
  12. Philipp Klaus Krause

    Tim Rentsch Guest

    Seebs <> writes:

    > On 2010-01-19, Ben Bacarisse <> wrote:
    >> Yes, this seems eminently possible. I thought you were not sure that
    >> this was possible.

    >
    > I'm not. There could be something I haven't thought of that prevents _Bool
    > from being allowed to have a trap representation.


    A regular _Bool can be a trap representation. A _Bool bitfield
    cannot be a trap representation, even if the bitfield has a width
    greater than one, which apparently is allowed.
     
    Tim Rentsch, Jan 20, 2010
    #12
  13. Tim Rentsch <> writes:

    > Seebs <> writes:
    >
    >> On 2010-01-19, Ben Bacarisse <> wrote:
    >>> Yes, this seems eminently possible. I thought you were not sure that
    >>> this was possible.

    >>
    >> I'm not. There could be something I haven't thought of that prevents _Bool
    >> from being allowed to have a trap representation.

    >
    > A regular _Bool can be a trap representation. A _Bool bitfield
    > cannot be a trap representation, even if the bitfield has a width
    > greater than one, which apparently is allowed.


    That's interesting. I can't see why a _Bool bit-field would be
    different from a normal _Bool object. What is the reasoning?

    --
    Ben.
     
    Ben Bacarisse, Jan 20, 2010
    #13
  14. Philipp Klaus Krause

    Tim Rentsch Guest

    Ben Bacarisse <> writes:

    > Tim Rentsch <> writes:
    >
    >> Seebs <> writes:
    >>
    >>> On 2010-01-19, Ben Bacarisse <> wrote:
    >>>> Yes, this seems eminently possible. I thought you were not sure that
    >>>> this was possible.
    >>>
    >>> I'm not. There could be something I haven't thought of that prevents _Bool
    >>> from being allowed to have a trap representation.

    >>
    >> A regular _Bool can be a trap representation. A _Bool bitfield
    >> cannot be a trap representation, even if the bitfield has a width
    >> greater than one, which apparently is allowed.

    >
    > That's interesting. I can't see why a _Bool bit-field would be
    > different from a normal _Bool object. What is the reasoning?


    A bit-field is interpreted as a signed or unsigned integer type
    consisting of the specified number of bits. (6.7.2.1p9)

    Values stored in unsigned bit-fields and objects of type unsigned
    char shall be represented using a pure binary notation. (6.2.6.1p3)

    (For unsigned integer types) If there are N value bits, each bit
    shall represent a different power of 2 between 1 and 2**(N-1), so
    that objects of that type shall be capable of representing values
    from 0 to (2**N)-1 using a pure binary representation. (6.2.6.2p1)

    The type _Bool is an unsigned integer type. (6.2.5p6)


    I admit, it seems strange that a _Bool bitfield might be required to
    represent values other than 0 and 1, but apparently that's true if
    an implementation admits a _Bool bitfield of width greater than one
    (which I think is allowed but not required). Maybe <limits.h>
    should have a new entry, BOOL_MAX, for the maximum value that can be
    represented in a _Bool bitfield. How scary is that?
     
    Tim Rentsch, Jan 21, 2010
    #14
  15. Tim Rentsch <> writes:

    > Ben Bacarisse <> writes:
    >
    >> Tim Rentsch <> writes:

    <snip>
    >>> A regular _Bool can be a trap representation. A _Bool bitfield
    >>> cannot be a trap representation, even if the bitfield has a width
    >>> greater than one, which apparently is allowed.

    >>
    >> That's interesting. I can't see why a _Bool bit-field would be
    >> different from a normal _Bool object. What is the reasoning?

    >
    > A bit-field is interpreted as a signed or unsigned integer type
    > consisting of the specified number of bits. (6.7.2.1p9)
    >
    > Values stored in unsigned bit-fields and objects of type unsigned
    > char shall be represented using a pure binary notation. (6.2.6.1p3)


    This is the part I was missing. Thanks.

    > (For unsigned integer types) If there are N value bits, each bit
    > shall represent a different power of 2 between 1 and 2**(N-1), so
    > that objects of that type shall be capable of representing values
    > from 0 to (2**N)-1 using a pure binary representation. (6.2.6.2p1)
    >
    > The type _Bool is an unsigned integer type. (6.2.5p6)
    >
    >
    > I admit, it seems strange that a _Bool bitfield might be required to
    > represent values other than 0 and 1, but apparently that's true if
    > an implementation admits a _Bool bitfield of width greater than one
    > (which I think is allowed but not required). Maybe <limits.h>
    > should have a new entry, BOOL_MAX, for the maximum value that can be
    > represented in a _Bool bitfield. How scary is that?


    I think we need it for non-bit-field _Bool objects as well! If a _Bool
    bit-field has a width > 1 it means that plain _Bool has a width > 1;
    i.e. that is has more than 1 value bit.

    Because of 6.3.1.2 p1, the only way to get such a value into it is by
    byte copying, but once there the value must come out. Of course, an
    implementation may mandate that the width of _Bool is 1 (with the rest
    of the bit being padding bits) but then _Bool bit-fields as also
    limited to a with of 1.

    gcc, for one, seems to give _Bool CHAR_BIT value bits. The effect is
    that, given an object b of type_Bool, the expressions b and (_Bool)b
    need not have the same value. Is _Bool the only type with this
    property?

    --
    Ben.
     
    Ben Bacarisse, Jan 21, 2010
    #15
  16. Ben Bacarisse <> writes:
    [...]
    > gcc, for one, seems to give _Bool CHAR_BIT value bits. The effect is
    > that, given an object b of type_Bool, the expressions b and (_Bool)b
    > need not have the same value. Is _Bool the only type with this
    > property?


    As of gcc 4.3.3, sizeof (_Bool) is 1, but it appears that only one of
    the 8 bits is a value bit.

    If I try to declare a bool bit field wider than one bit, I get:

    error: width of 'b2' exceeds its type

    As for b vs. (_Bool)b, an experiment indicates that they yield the
    same result:

    #include <stdio.h>

    int main(void)
    {
    printf("sizeof (_Bool) = %zu\n", sizeof (_Bool));
    _Bool b_two;
    *(char*)&b_two = 2;
    char c_two = 2;
    printf("b_two = %d, (_Bool)b_two = %d\n", b_two, (_Bool)b_two);
    printf("c_two = %d, (_Bool)c_two = %d\n", c_two, (_Bool)c_two);
    return 0;
    }

    Output:

    sizeof (_Bool) = 1
    b_two = 2, (_Bool)b_two = 2
    c_two = 2, (_Bool)c_two = 1

    Hypothesis: _Bool has 1 value bit and 7 padding bits, and any
    representation where any of the padding bits are 1 is a trap
    representation. This means that any attempt to access the value
    of b_two invokes undefined behavior -- even a cast to _Bool; the
    compiler assumes that the stored value must be either 0 or 1, so
    it doesn't need to normalize any non-zero value to 1, as it does
    for types other than _Bool.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jan 22, 2010
    #16
  17. Keith Thompson <> writes:

    > Ben Bacarisse <> writes:
    > [...]
    >> gcc, for one, seems to give _Bool CHAR_BIT value bits. The effect is
    >> that, given an object b of type_Bool, the expressions b and (_Bool)b
    >> need not have the same value. Is _Bool the only type with this
    >> property?

    >
    > As of gcc 4.3.3, sizeof (_Bool) is 1, but it appears that only one of
    > the 8 bits is a value bit.
    >
    > If I try to declare a bool bit field wider than one bit, I get:
    >
    > error: width of 'b2' exceeds its type
    >
    > As for b vs. (_Bool)b, an experiment indicates that they yield the
    > same result:
    >
    > #include <stdio.h>
    >
    > int main(void)
    > {
    > printf("sizeof (_Bool) = %zu\n", sizeof (_Bool));
    > _Bool b_two;
    > *(char*)&b_two = 2;
    > char c_two = 2;
    > printf("b_two = %d, (_Bool)b_two = %d\n", b_two, (_Bool)b_two);
    > printf("c_two = %d, (_Bool)c_two = %d\n", c_two, (_Bool)c_two);
    > return 0;
    > }
    >
    > Output:
    >
    > sizeof (_Bool) = 1
    > b_two = 2, (_Bool)b_two = 2
    > c_two = 2, (_Bool)c_two = 1
    >
    > Hypothesis: _Bool has 1 value bit and 7 padding bits, and any
    > representation where any of the padding bits are 1 is a trap
    > representation. This means that any attempt to access the value
    > of b_two invokes undefined behavior -- even a cast to _Bool; the
    > compiler assumes that the stored value must be either 0 or 1, so
    > it doesn't need to normalize any non-zero value to 1, as it does
    > for types other than _Bool.


    Perfectly possible. I don't think it is easy to tell if this is the
    case of not. An implementation need not support bit-fields wider than
    1 for _Bool even if _Bool has more than 1 value bit, so I can't (off
    hand) think of a way to tell if your or my hypothesis is correct.

    (I am being a bit glib -- I prefer yours as an explanation -- but I
    really don't know how to tell. Should not some aspect of this be
    implementation defined so as to ensure it is documented?)

    --
    Ben.
     
    Ben Bacarisse, Jan 22, 2010
    #17
  18. Philipp Klaus Krause

    Tim Rentsch Guest

    Ben Bacarisse <> writes:

    > Tim Rentsch <> writes:
    >
    >> Ben Bacarisse <> writes:
    >>
    >>> Tim Rentsch <> writes:

    > <snip>
    >>>> A regular _Bool can be a trap representation. A _Bool bitfield
    >>>> cannot be a trap representation, even if the bitfield has a width
    >>>> greater than one, which apparently is allowed.
    >>>
    >>> That's interesting. I can't see why a _Bool bit-field would be
    >>> different from a normal _Bool object. What is the reasoning?

    >>
    >> A bit-field is interpreted as a signed or unsigned integer type
    >> consisting of the specified number of bits. (6.7.2.1p9)
    >>
    >> Values stored in unsigned bit-fields and objects of type unsigned
    >> char shall be represented using a pure binary notation. (6.2.6.1p3)

    >
    > This is the part I was missing. Thanks.
    >
    >> (For unsigned integer types) If there are N value bits, each bit
    >> shall represent a different power of 2 between 1 and 2**(N-1), so
    >> that objects of that type shall be capable of representing values
    >> from 0 to (2**N)-1 using a pure binary representation. (6.2.6.2p1)
    >>
    >> The type _Bool is an unsigned integer type. (6.2.5p6)
    >>
    >>
    >> I admit, it seems strange that a _Bool bitfield might be required to
    >> represent values other than 0 and 1, but apparently that's true if
    >> an implementation admits a _Bool bitfield of width greater than one
    >> (which I think is allowed but not required). Maybe <limits.h>
    >> should have a new entry, BOOL_MAX, for the maximum value that can be
    >> represented in a _Bool bitfield. How scary is that?

    >
    > I think we need it for non-bit-field _Bool objects as well! If a _Bool
    > bit-field has a width > 1 it means that plain _Bool has a width > 1;
    > i.e. that is has more than 1 value bit.


    I see your point. Actually an implementation could define
    the width of plain _Bool to be 1 but still allow _Bool bitfields
    of width > 1, but being a constraint violation a diagnostic would
    be required. (That doesn't take away from your point, which is
    a good one.)

    > Because of 6.3.1.2 p1, the only way to get such a value into it is by
    > byte copying,


    .... or by using unions ...

    > but once there the value must come out. Of course, an
    > implementation may mandate that the width of _Bool is 1 (with the rest
    > of the bit being padding bits) but then _Bool bit-fields as also
    > limited to a with of 1.


    Again, wider _Bool bitfields could still be allowed as long as
    a diagnostic is given.

    > gcc, for one, seems to give _Bool CHAR_BIT value bits. The effect is
    > that, given an object b of type_Bool, the expressions b and (_Bool)b
    > need not have the same value. Is _Bool the only type with this
    > property?


    I believe the floating-point types also can exhibit this behavior
    (ie, and still be conforming).
     
    Tim Rentsch, Jan 22, 2010
    #18
  19. Philipp Klaus Krause

    Tim Rentsch Guest

    Keith Thompson <> writes:

    > Ben Bacarisse <> writes:
    > [...]
    >> gcc, for one, seems to give _Bool CHAR_BIT value bits. The effect is
    >> that, given an object b of type_Bool, the expressions b and (_Bool)b
    >> need not have the same value. Is _Bool the only type with this
    >> property?

    >
    > As of gcc 4.3.3, sizeof (_Bool) is 1, but it appears that only one of
    > the 8 bits is a value bit.
    >
    > If I try to declare a bool bit field wider than one bit, I get:
    >
    > error: width of 'b2' exceeds its type


    To to report: I got a different result in an earlier version of gcc
    (don't remember which one offhand) -- _Bool bitfields were allowed up
    to a width of 8 (and CHAR_BIT was also 8).

    > As for b vs. (_Bool)b, an experiment indicates that they yield the
    > same result:
    >
    > #include <stdio.h>
    >
    > int main(void)
    > {
    > printf("sizeof (_Bool) = %zu\n", sizeof (_Bool));
    > _Bool b_two;
    > *(char*)&b_two = 2;
    > char c_two = 2;
    > printf("b_two = %d, (_Bool)b_two = %d\n", b_two, (_Bool)b_two);
    > printf("c_two = %d, (_Bool)c_two = %d\n", c_two, (_Bool)c_two);
    > return 0;
    > }
    >
    > Output:
    >
    > sizeof (_Bool) = 1
    > b_two = 2, (_Bool)b_two = 2
    > c_two = 2, (_Bool)c_two = 1


    This could be the result of undefined behavior, but it weren't (ie,
    because the width of _Bool were greater than 1) the expressions b_two
    and (_Bool) b_two still should yield the same result, because of the
    rule that converting to the same type as the operand type causes no
    change to the value or the representation.

    > Hypothesis: _Bool has 1 value bit and 7 padding bits, and any
    > representation where any of the padding bits are 1 is a trap
    > representation.


    Presumably that's true in this implementation; certainly it
    could be true (in this implementation). But it doesn't have to
    be true in other implementations.

    > This means that any attempt to access the value
    > of b_two invokes undefined behavior -- even a cast to _Bool; the
    > compiler assumes that the stored value must be either 0 or 1, so
    > it doesn't need to normalize any non-zero value to 1, as it does
    > for types other than _Bool.


    Again, in this implementation. In another implementation, where
    the width of _Bool is CHAR_BIT (and where sizeof (_Bool) == 1),
    the behavior would be defined -- implementation-specific, to be
    sure, but necessarily defined in that implementation.
     
    Tim Rentsch, Jan 22, 2010
    #19
  20. Philipp Klaus Krause

    Tim Rentsch Guest

    Ben Bacarisse <> writes:

    > Keith Thompson <> writes:
    >
    >> Ben Bacarisse <> writes:
    >> [...]
    >>> gcc, for one, seems to give _Bool CHAR_BIT value bits. The effect is
    >>> that, given an object b of type_Bool, the expressions b and (_Bool)b
    >>> need not have the same value. Is _Bool the only type with this
    >>> property?

    >>
    >> As of gcc 4.3.3, sizeof (_Bool) is 1, but it appears that only one of
    >> the 8 bits is a value bit.
    >>
    >> If I try to declare a bool bit field wider than one bit, I get:
    >>
    >> error: width of 'b2' exceeds its type
    >>
    >> As for b vs. (_Bool)b, an experiment indicates that they yield the
    >> same result:
    >>
    >> #include <stdio.h>
    >>
    >> int main(void)
    >> {
    >> printf("sizeof (_Bool) = %zu\n", sizeof (_Bool));
    >> _Bool b_two;
    >> *(char*)&b_two = 2;
    >> char c_two = 2;
    >> printf("b_two = %d, (_Bool)b_two = %d\n", b_two, (_Bool)b_two);
    >> printf("c_two = %d, (_Bool)c_two = %d\n", c_two, (_Bool)c_two);
    >> return 0;
    >> }
    >>
    >> Output:
    >>
    >> sizeof (_Bool) = 1
    >> b_two = 2, (_Bool)b_two = 2
    >> c_two = 2, (_Bool)c_two = 1
    >>
    >> Hypothesis: _Bool has 1 value bit and 7 padding bits, and any
    >> representation where any of the padding bits are 1 is a trap
    >> representation. This means that any attempt to access the value
    >> of b_two invokes undefined behavior -- even a cast to _Bool; the
    >> compiler assumes that the stored value must be either 0 or 1, so
    >> it doesn't need to normalize any non-zero value to 1, as it does
    >> for types other than _Bool.

    >
    > Perfectly possible. I don't think it is easy to tell if this is the
    > case of not. An implementation need not support bit-fields wider than
    > 1 for _Bool even if _Bool has more than 1 value bit,


    I don't know where you're getting this. My reading is that, if the
    width of _Bool is N > 1, then programs are allowed to use _Bool
    bitfields of width up to N, and therefore implementations are
    required to support them. (The quantity N may be any value between
    1 and CHAR_BIT.) So if an implementation doesn't accept _Bool
    bitfields of width > 1, I don't see how it's possible for the width
    of _Bool in that implementation to be anything other than 1.

    [And therefore, to complete Keith's argument, the only way to get a
    value other than 0 or 1 out of a _Bool variable, with _Bool having a
    width of 1, is for (at least some of) the padding bits to produce trap
    representations.]

    > so I can't (off
    > hand) think of a way to tell if your or my hypothesis is correct.
    >
    > (I am being a bit glib -- I prefer yours as an explanation -- but I
    > really don't know how to tell. Should not some aspect of this be
    > implementation defined so as to ensure it is documented?)


    Absolutely. Even if (as I think it is) it is possible to tell the
    width of _Bool by the width of _Bool bitfields that an implementation
    accepts, either the width of _Bool, or BOOL_MAX, or something similar,
    should still be implmentation-defined. Then if the width of _Bool
    were anything less than sizeof (_Bool) * CHAR_BIT, the possibility
    of trap representations could be inferred.
     
    Tim Rentsch, Jan 22, 2010
    #20
    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. Oliver Wong
    Replies:
    11
    Views:
    939
    Hendrik Maryns
    Apr 19, 2006
  2. PSN
    Replies:
    2
    Views:
    327
  3. asit

    uninitialized variable

    asit, Jun 9, 2009, in forum: Java
    Replies:
    13
    Views:
    662
    John B. Matthews
    Jun 17, 2009
  4. Gavin Sinclair
    Replies:
    9
    Views:
    152
    Martin DeMello
    Dec 29, 2003
  5. Alextophi
    Replies:
    2
    Views:
    159
    Alextophi
    Sep 14, 2005
Loading...

Share This Page