Uninitialized auto variables

Discussion in 'C Programming' started by Spoon, Jul 30, 2007.

  1. Spoon

    Spoon Guest

    Hello everyone,

    I suppose using uninitialized automatic integer variables leads
    to undefined behavior?

    i.e.

    int foo(void)
    {
    int bar; /* bar may be 0, or it may be non-0 */
    return bar;
    }

    I sometimes do that when I need an int, any int.

    I suppose this is a bad habit? :)

    Regards.
     
    Spoon, Jul 30, 2007
    #1
    1. Advertising

  2. Spoon

    Chris Dollin Guest

    Spoon wrote:

    > Hello everyone,
    >
    > I suppose using uninitialized automatic integer variables leads
    > to undefined behavior?


    Yes.

    > int foo(void)
    > {
    > int bar; /* bar may be 0, or it may be non-0 */
    > return bar;
    > }
    >
    > I sometimes do that when I need an int, any int.
    >
    > I suppose this is a bad habit? :)


    Very.

    (If "any int" will do, zero is a convenient value.)

    --
    Far-Fetched Hedgehog
    "We did not have time to find out everything we wanted to know."
    - James Blish, /A Clash of Cymbals/
     
    Chris Dollin, Jul 30, 2007
    #2
    1. Advertising

  3. Spoon

    santosh Guest

    Spoon wrote:

    > Hello everyone,
    >
    > I suppose using uninitialized automatic integer variables leads
    > to undefined behavior?


    Yes.

    > i.e.
    >
    > int foo(void)
    > {
    > int bar; /* bar may be 0, or it may be non-0 */
    > return bar;
    > }
    >
    > I sometimes do that when I need an int, any int.
    >
    > I suppose this is a bad habit? :)


    Yes. If you need a random integer, just use the rand Standard library
    function.

    man 3 rand
     
    santosh, Jul 30, 2007
    #3
  4. Spoon <root@localhost> writes:
    > I suppose using uninitialized automatic integer variables leads
    > to undefined behavior?
    >
    > i.e.
    >
    > int foo(void)
    > {
    > int bar; /* bar may be 0, or it may be non-0 */
    > return bar;
    > }
    >
    > I sometimes do that when I need an int, any int.
    >
    > I suppose this is a bad habit? :)


    Yes.

    What are the circumstances in which you need "an int, any int" but
    don't care about the value?

    --
    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, Jul 30, 2007
    #4
  5. Spoon

    Spoon Guest

    Keith Thompson wrote:

    > Spoon wrote:
    >
    >> I suppose using uninitialized automatic integer variables leads
    >> to undefined behavior?
    >>
    >> i.e.
    >>
    >> int foo(void)
    >> {
    >> int bar; /* bar may be 0, or it may be non-0 */
    >> return bar;
    >> }
    >>
    >> I sometimes do that when I need an int, any int.
    >>
    >> I suppose this is a bad habit? :)

    >
    > Yes.
    >
    > What are the circumstances in which you need "an int, any int" but
    > don't care about the value?


    For example, an opaque identifier. Any value will do.

    I suppose rand() is a much better option.
     
    Spoon, Jul 30, 2007
    #5
  6. In article <46adac8b$0$28621$>,
    Spoon <root@localhost> wrote:

    >>> int foo(void)
    >>> {
    >>> int bar; /* bar may be 0, or it may be non-0 */
    >>> return bar;
    >>> }
    >>>
    >>> I sometimes do that when I need an int, any int.


    >> What are the circumstances in which you need "an int, any int" but
    >> don't care about the value?


    >For example, an opaque identifier. Any value will do.


    When do you need opaque identifiers but not care about whether they're
    different? Why not just use "45576" instead of "foo()"?

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Jul 30, 2007
    #6
  7. Spoon

    Spoon Guest

    Richard Tobin wrote:
    > In article <46adac8b$0$28621$>,
    > Spoon <root@localhost> wrote:
    >
    >>>> int foo(void)
    >>>> {
    >>>> int bar; /* bar may be 0, or it may be non-0 */
    >>>> return bar;
    >>>> }
    >>>>
    >>>> I sometimes do that when I need an int, any int.

    >
    >>> What are the circumstances in which you need "an int, any int" but
    >>> don't care about the value?

    >
    >> For example, an opaque identifier. Any value will do.

    >
    > When do you need opaque identifiers but not care about whether they're
    > different? Why not just use "45576" instead of "foo()"?


    I only needed one identifier per run.
    (It didn't matter if it was the same identifier on the next run.)
    I won't do it anymore, now that I know it leads to UB.
     
    Spoon, Jul 30, 2007
    #7
  8. Spoon

    Mark Bluemel Guest

    Spoon wrote:
    > Richard Tobin wrote:
    >
    >> In article <46adac8b$0$28621$>,
    >> Spoon <root@localhost> wrote:


    >>> ... an opaque identifier. Any value will do.

    >>
    >>
    >> When do you need opaque identifiers but not care about whether they're
    >> different? Why not just use "45576" instead of "foo()"?

    >
    > I only needed one identifier per run.


    If there's only one, why do you need it at all? I don't need to be able
    to differentiate myself from myself.
     
    Mark Bluemel, Jul 30, 2007
    #8
  9. Spoon

    CBFalconer Guest

    Richard Tobin wrote:
    > Spoon <root@localhost> wrote:
    >

    .... snip ...
    >
    >> For example, an opaque identifier. Any value will do.

    >
    > When do you need opaque identifiers but not care about whether
    > they're different? Why not just use "45576" instead of "foo()"?


    For one reason, because the guaranteed minimum maximm integer value
    is 32767.

    --
    <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, Jul 30, 2007
    #9
  10. santosh wrote:
    > Spoon wrote:
    >
    >> Hello everyone,
    >>
    >> I suppose using uninitialized automatic integer variables leads
    >> to undefined behavior?

    >
    > Yes.

    Could you please point me to the paragraph of the standard where it's
    told to be so?

    I can only find this sentence in WG14/N1124, 6.2.4.5

    "...The initial value of the object is indeterminate...."

    Which doesn't mean, to my understanding, that using it invokes UB.

    Thanks for clarifying this point!

    >
    >> i.e.
    >>
    >> int foo(void)
    >> {
    >> int bar; /* bar may be 0, or it may be non-0 */
    >> return bar;
    >> }
    >>
    >> I sometimes do that when I need an int, any int.
    >>
    >> I suppose this is a bad habit? :)

    >
    > Yes. If you need a random integer, just use the rand Standard library
    > function.
    >
    > man 3 rand
    >



    --
    Pietro Cerutti

    PGP Public Key:
    http://gahr.ch/pgp
     
    Pietro Cerutti, Jul 30, 2007
    #10
  11. Spoon

    pete Guest

    Spoon wrote:
    >
    > Hello everyone,
    >
    > I suppose using uninitialized automatic integer variables leads
    > to undefined behavior?
    >
    > i.e.
    >
    > int foo(void)
    > {
    > int bar; /* bar may be 0, or it may be non-0 */


    /*
    ** The undefined part of the situation, is that bar may be (-0),
    ** and that the implementation may or may not trap on (-0).
    */

    > return bar;
    > }
    >
    > I sometimes do that when I need an int, any int.
    >
    > I suppose this is a bad habit? :)


    You suppose correctly.

    --
    pete
     
    pete, Jul 30, 2007
    #11
  12. Spoon

    Spoon Guest

    pete wrote:

    > Spoon wrote:
    >
    >> I suppose using uninitialized automatic integer variables leads
    >> to undefined behavior?
    >>
    >> i.e.
    >>
    >> int foo(void)
    >> {
    >> int bar; /* bar may be 0, or it may be non-0 */

    >
    > /*
    > ** The undefined part of the situation, is that bar may be (-0),
    > ** and that the implementation may or may not trap on (-0).
    > */


    (If it makes a difference, I use a C89 compiler.)

    Does the problem remain with unsigned ints?

    i.e.

    unsigned foo2(void)
    {
    unsigned bar2; /* bar may be 0, or it may be non-0 */
    return bar;
    }

    --
    Regards.
     
    Spoon, Jul 30, 2007
    #12
  13. Spoon

    CryptiqueGuy Guest

    On Jul 30, 3:32 pm, Pietro Cerutti <> wrote:
    > santosh wrote:
    > > Spoon wrote:

    >
    > >> Hello everyone,

    >
    > >> I suppose using uninitialized automatic integer variables leads
    > >> to undefined behavior?

    >
    > > Yes.

    >
    > Could you please point me to the paragraph of the standard where it's
    > told to be so?
    >
    > I can only find this sentence in WG14/N1124, 6.2.4.5
    >
    > "...The initial value of the object is indeterminate...."
    >
    > Which doesn't mean, to my understanding, that using it invokes UB.


    >From 6.2.6.1:


    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.


    Standards doesn't prohibit an uninitialized value to have a trap
    representation. So it is a UB.
     
    CryptiqueGuy, Jul 30, 2007
    #13
  14. CryptiqueGuy wrote:
    > On Jul 30, 3:32 pm, Pietro Cerutti <> wrote:
    >> santosh wrote:
    >>> Spoon wrote:
    >>>> Hello everyone,
    >>>> I suppose using uninitialized automatic integer variables leads
    >>>> to undefined behavior?
    >>> Yes.

    >> Could you please point me to the paragraph of the standard where it's
    >> told to be so?
    >>
    >> I can only find this sentence in WG14/N1124, 6.2.4.5
    >>
    >> "...The initial value of the object is indeterminate...."
    >>
    >> Which doesn't mean, to my understanding, that using it invokes UB.

    >
    >>From 6.2.6.1:

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


    Thank you!

    And it's even more clearly stated in foot note 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."

    Regards

    --
    Pietro Cerutti

    PGP Public Key:
    http://gahr.ch/pgp
     
    Pietro Cerutti, Jul 30, 2007
    #14
  15. Spoon

    Chris Dollin Guest

    Spoon wrote:

    > pete wrote:
    >
    >> Spoon wrote:
    >>
    >>> I suppose using uninitialized automatic integer variables leads
    >>> to undefined behavior?
    >>>
    >>> i.e.
    >>>
    >>> int foo(void)
    >>> {
    >>> int bar; /* bar may be 0, or it may be non-0 */

    >>
    >> /*
    >> ** The undefined part of the situation, is that bar may be (-0),
    >> ** and that the implementation may or may not trap on (-0).
    >> */

    >
    > (If it makes a difference, I use a C89 compiler.)
    >
    > Does the problem remain with unsigned ints?
    >
    > i.e.
    >
    > unsigned foo2(void)
    > {
    > unsigned bar2; /* bar may be 0, or it may be non-0 */
    > return bar;
    > }


    Assuming `bar` was supposed to be `bar2`, that gets UB.
    The signedness has nothing to do with it.

    --
    Far-Fetched Hedgehog
    Notmuchhere: http://www.electrichedgehog.net/
     
    Chris Dollin, Jul 30, 2007
    #15
  16. Spoon

    Spoon Guest

    Chris Dollin wrote:

    > Spoon wrote:
    >
    >> pete wrote:
    >>
    >>> Spoon wrote:
    >>>
    >>>> I suppose using uninitialized automatic integer variables leads
    >>>> to undefined behavior?
    >>>>
    >>>> i.e.
    >>>>
    >>>> int foo(void)
    >>>> {
    >>>> int bar; /* bar may be 0, or it may be non-0 */
    >>> /*
    >>> ** The undefined part of the situation, is that bar may be (-0),
    >>> ** and that the implementation may or may not trap on (-0).
    >>> */

    >> (If it makes a difference, I use a C89 compiler.)
    >>
    >> Does the problem remain with unsigned ints?
    >>
    >> i.e.
    >>
    >> unsigned foo2(void)
    >> {
    >> unsigned bar2; /* bar may be 0, or it may be non-0 */
    >> return bar;
    >> }

    >
    > Assuming `bar` was supposed to be `bar2`, that gets UB.


    Doh! Yes, I meant bar2.

    > The signedness has nothing to do with it.


    I had the vague belief that trap representations were not allowed (?)
    for unsigned integers.
     
    Spoon, Jul 30, 2007
    #16
  17. Spoon

    Chris Dollin Guest

    Spoon wrote:

    > Chris Dollin wrote:
    >
    >> Spoon wrote:
    >>
    >>> pete wrote:
    >>>
    >>>> Spoon wrote:
    >>>>
    >>>>> I suppose using uninitialized automatic integer variables leads
    >>>>> to undefined behavior?
    >>>>>
    >>>>> i.e.
    >>>>>
    >>>>> int foo(void)
    >>>>> {
    >>>>> int bar; /* bar may be 0, or it may be non-0 */
    >>>> /*
    >>>> ** The undefined part of the situation, is that bar may be (-0),
    >>>> ** and that the implementation may or may not trap on (-0).
    >>>> */
    >>> (If it makes a difference, I use a C89 compiler.)
    >>>
    >>> Does the problem remain with unsigned ints?
    >>>
    >>> i.e.
    >>>
    >>> unsigned foo2(void)
    >>> {
    >>> unsigned bar2; /* bar may be 0, or it may be non-0 */
    >>> return bar;
    >>> }

    >>
    >> Assuming `bar` was supposed to be `bar2`, that gets UB.

    >
    > Doh! Yes, I meant bar2.
    >
    >> The signedness has nothing to do with it.

    >
    > I had the vague belief that trap representations were not allowed (?)
    > for unsigned integers.


    I'm not sure that matters; doesn't the Standard say that the
    mere use of an indeterminate value produces UB? (I can't
    quickly find n689; the evil twin has a copy on his machine,
    but he's not at work today.)

    [At this moment I don't see why an implementation can't have
    a /determinate/ bit for every object & value, independently
    of any value bits those have, and do as it likes once it
    finds a value with that bit unset.]

    --
    Far-Fetched Hedgehog
    The shortcuts are all full of people using them.
     
    Chris Dollin, Jul 30, 2007
    #17
  18. Chris Dollin wrote:
    > Spoon wrote:
    >
    >> Chris Dollin wrote:
    >>
    >>> Spoon wrote:
    >>>
    >>>> pete wrote:
    >>>>
    >>>>> Spoon wrote:
    >>>>>
    >>>>>> I suppose using uninitialized automatic integer variables leads
    >>>>>> to undefined behavior?
    >>>>>>
    >>>>>> i.e.
    >>>>>>
    >>>>>> int foo(void)
    >>>>>> {
    >>>>>> int bar; /* bar may be 0, or it may be non-0 */
    >>>>> /*
    >>>>> ** The undefined part of the situation, is that bar may be (-0),
    >>>>> ** and that the implementation may or may not trap on (-0).
    >>>>> */
    >>>> (If it makes a difference, I use a C89 compiler.)
    >>>>
    >>>> Does the problem remain with unsigned ints?
    >>>>
    >>>> i.e.
    >>>>
    >>>> unsigned foo2(void)
    >>>> {
    >>>> unsigned bar2; /* bar may be 0, or it may be non-0 */
    >>>> return bar;
    >>>> }
    >>>
    >>> Assuming `bar` was supposed to be `bar2`, that gets UB.

    >>
    >> Doh! Yes, I meant bar2.
    >>
    >>> The signedness has nothing to do with it.

    >>
    >> I had the vague belief that trap representations were not allowed (?)
    >> for unsigned integers.


    That's specific to unsigned char (and perhaps unsigned bit-fields; I haven't
    checked). All other integer types are allowed to have trap representations.

    > I'm not sure that matters; doesn't the Standard say that the
    > mere use of an indeterminate value produces UB? (I can't
    > quickly find n689; the evil twin has a copy on his machine,
    > but he's not at work today.)


    No, the standard doesn't say that anymore. C90 did, but when C99 added the
    concept of trap representations, indeterminate values gave either an
    unspecified value, or a trap representation. When there is no trap
    representation, an indeterminate value is always a valid value.

    > [At this moment I don't see why an implementation can't have
    > a /determinate/ bit for every object & value, independently
    > of any value bits those have, and do as it likes once it
    > finds a value with that bit unset.]


    This would be allowed in C90, but not in C99. I believe I've seen a request
    for that to be permitted in the next standard again, however, because of
    real implementation problems caused by unsigned char always having a valid
    value.
     
    Harald van =?UTF-8?B?RMSzaw==?=, Jul 30, 2007
    #18
  19. Spoon

    Chris Dollin Guest

    Harald van Dijk wrote:

    > Chris Dollin wrote:
    >
    >> I'm not sure that matters; doesn't the Standard say that the
    >> mere use of an indeterminate value produces UB? (I can't
    >> quickly find n689; the evil twin has a copy on his machine,
    >> but he's not at work today.)

    >
    > No, the standard doesn't say that anymore. C90 did, but when C99 added the
    > concept of trap representations, indeterminate values gave either an
    > unspecified value, or a trap representation. When there is no trap
    > representation, an indeterminate value is always a valid value.


    Ah. Mired in the past, that's me.

    >> [At this moment I don't see why an implementation can't have
    >> a /determinate/ bit for every object & value, independently
    >> of any value bits those have, and do as it likes once it
    >> finds a value with that bit unset.]

    >
    > This would be allowed in C90, but not in C99. I believe I've seen a
    > request for that to be permitted in the next standard again, however,
    > because of real implementation problems caused by unsigned char always
    > having a valid value.


    And, one would have thought, because one wants debugging implementations
    to be able to catch the use of indeterminate values.

    Thanks for the correction.

    --
    Determined Hedgehog
    Nit-picking is best done among friends.
     
    Chris Dollin, Jul 30, 2007
    #19
  20. On Mon, 30 Jul 2007 12:32:41 +0200, Pietro Cerutti <>
    wrote:

    >santosh wrote:
    >> Spoon wrote:
    >>
    >>> Hello everyone,
    >>>
    >>> I suppose using uninitialized automatic integer variables leads
    >>> to undefined behavior?

    >>
    >> Yes.

    >Could you please point me to the paragraph of the standard where it's
    >told to be so?
    >
    >I can only find this sentence in WG14/N1124, 6.2.4.5
    >
    >"...The initial value of the object is indeterminate...."
    >
    >Which doesn't mean, to my understanding, that using it invokes UB.
    >
    >Thanks for clarifying this point!


    It's covered in N1124, Appendix J.2, tenth item down.


    Remove del for email
     
    Barry Schwarz, Jul 31, 2007
    #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. Adel
    Replies:
    3
    Views:
    329
    Jack Klein
    Mar 17, 2005
  3. Replies:
    12
    Views:
    674
    Randy Howard
    Oct 1, 2005
  4. linkswanted
    Replies:
    1
    Views:
    996
  5. C.S.M.G.Sarma
    Replies:
    6
    Views:
    881
    Ben Bacarisse
    Jul 15, 2010
Loading...

Share This Page