do/while loop and scope of automatic vars

Discussion in 'C Programming' started by Erik de Castro Lopo, Aug 21, 2007.

  1. Hi all,

    Consider the following code snippet:

    do
    {
    int r = rand () ;
    } while (r != 0) ;

    It seems the compiler I'm using (GCC) does realise that the
    scope of variable r extends the end of the while's conditional.

    Questions:

    - Is this correct according to the ISO/ANSI C standards?
    - If so, can someone point me to the section of the ISO
    C99 stanard whic defines this?

    TIA,
    Erik
    --
    -----------------------------------------------------------------
    Erik de Castro Lopo
    -----------------------------------------------------------------
    Of the four project development variables - scope, cost, time and
    quality - quality isn't really a free variable. The only possible
    values are "excellent" and "insanely excellent", depending on
    whether lives are at stake." -- Kent Beck, XP Explained
    Erik de Castro Lopo, Aug 21, 2007
    #1
    1. Advertising

  2. Erik de Castro Lopo <> writes:
    > Consider the following code snippet:
    >
    > do
    > {
    > int r = rand () ;
    > } while (r != 0) ;
    >
    > It seems the compiler I'm using (GCC) does realise that the
    > scope of variable r extends the end of the while's conditional.
    >
    > Questions:
    >
    > - Is this correct according to the ISO/ANSI C standards?
    > - If so, can someone point me to the section of the ISO
    > C99 stanard whic defines this?


    Did you mean to write that it *doesn't" realize that the scope extends
    to the end of the conditional?

    When I wrap your code in a main program and compile it with gcc, I get:

    c.c: In function `main':
    c.c:7: error: `r' undeclared (first use in this function)
    c.c:7: error: (Each undeclared identifier is reported only once
    c.c:7: error: for each function it appears in.)

    gcc is correct. C99 6.2.1p4 says:

    If the declarator or type specifier that declares the identifier
    appears inside a block or within the list of parameter
    declarations in a function definition, the identifier has _block
    scope_, which terminates at the end of the associated block.

    The block extends from the opening '{' to the closing '}'.

    --
    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, Aug 21, 2007
    #2
    1. Advertising

  3. On Aug 20, 11:01 pm, Erik de Castro Lopo <> wrote:
    > Hi all,
    >
    > Consider the following code snippet:
    >
    > do
    > {
    > int r = rand () ;
    > } while (r != 0) ;
    >
    > It seems the compiler I'm using (GCC) does realise that the
    > scope of variable r extends the end of the while's conditional.


    Because it doesn't.

    >
    > Questions:
    >
    > - Is this correct according to the ISO/ANSI C standards?


    No.

    > - If so, can someone point me to the section of the ISO
    > C99 stanard whic defines this?


    §6.2.1p4:
    "...If the declarator or type specifier that declares the identifier
    appears inside a block or within the list of parameter declarations in
    a function definition, the identifier has block scope, which
    terminates at the end of the associated block."

    §6.8.5p4-5
    "An iteration statement causes a statement called the loop body to be
    executed repeatedly
    until the controlling expression compares equal to 0.

    An iteration statement is a block whose scope is a strict subset of
    the scope of its
    enclosing block. The loop body is also a block whose scope is a strict
    subset of the scope
    of the iteration statement."

    The loop body is a block, the variable r is declared in this block.
    The scope of the variable extends to the end of the associated block
    of which the controlling expression is not a part.

    Robert Gamble
    Robert Gamble, Aug 21, 2007
    #3
  4. Erik de Castro Lopo

    Eric Sosman Guest

    Erik de Castro Lopo wrote:
    > Hi all,
    >
    > Consider the following code snippet:
    >
    > do
    > {
    > int r = rand () ;
    > } while (r != 0) ;
    >
    > It seems the compiler I'm using (GCC) does realise that the
    > scope of variable r extends the end of the while's conditional.


    The scope of the `r' inside the { } ends at the closing }.
    The `r' in the while clause is some other `r' from an enclosing
    scope.

    > Questions:
    >
    > - Is this correct according to the ISO/ANSI C standards?
    > - If so, can someone point me to the section of the ISO
    > C99 stanard whic defines this?


    6.8.5p5: "An iteration statement is a block whose scope is
    a strict subset of the scope of its enclosing block. The loop
    body is also a block whose scope is a strict subset of the scope
    of the iteration statement."

    See also 6.2.1p4 for the definition of "block scope."

    --
    Eric Sosman
    lid
    Eric Sosman, Aug 21, 2007
    #4
  5. Erik de Castro Lopo

    CBFalconer Guest

    Erik de Castro Lopo wrote:
    >
    > Consider the following code snippet:
    >
    > do
    > {
    > int r = rand () ;
    > } while (r != 0) ;
    >
    > It seems the compiler I'm using (GCC) does realise that the
    > scope of variable r extends the end of the while's conditional.
    >
    > Questions:
    >
    > - Is this correct according to the ISO/ANSI C standards?
    > - If so, can someone point me to the section of the ISO
    > C99 stanard whic defines this?


    Consider that rand may never return the value 0, in which case the
    loop will run forever. The only possible use of this is to advance
    the rand generator to the point where it has just returned zero.
    The value(s) returned are not available anywhere. And that is IF
    the scope of r extends through the conditional, which may not be so
    for another compiler. Whether or not it should is another matter
    entirely.

    Simpler code with the same faults and no scope problem is:

    do {
    /* nada */
    } while (rand());

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Aug 21, 2007
    #5
  6. CBFalconer wrote:
    >
    > Erik de Castro Lopo wrote:
    > >
    > > Consider the following code snippet:
    > >
    > > do
    > > {
    > > int r = rand () ;
    > > } while (r != 0) ;
    > >
    > > It seems the compiler I'm using (GCC) does realise that the
    > > scope of variable r extends the end of the while's conditional.
    > >
    > > Questions:
    > >
    > > - Is this correct according to the ISO/ANSI C standards?
    > > - If so, can someone point me to the section of the ISO
    > > C99 stanard whic defines this?


    My C90 compiler doesn't allow this. As others have pointed out,
    "r" is not in scope outside of the loop, and should not exist for
    the "while" statement.

    > Consider that rand may never return the value 0, in which case the
    > loop will run forever. The only possible use of this is to advance
    > the rand generator to the point where it has just returned zero.


    I took this as simply a sample snippet to demonstrate the "should
    'r' be in scope for the 'while' statement" question, not as a
    real-life code snippet. We often post "useless" snippets of code
    here, simply to boil it down to the simplest wasy of demonstrating
    what we are asking.

    [...]

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Aug 21, 2007
    #6
  7. Erik de Castro Lopo

    Army1987 Guest

    On Tue, 21 Aug 2007 15:04:57 -0400, Kenneth Brody wrote:

    > I took this as simply a sample snippet to demonstrate the "should
    > 'r' be in scope for the 'while' statement" question, not as a
    > real-life code snippet. We often post "useless" snippets of code
    > here, simply to boil it down to the simplest wasy of demonstrating
    > what we are asking.


    <ot>
    In the comp.lang.c++ FAQ there is a snippet of code which, to show
    a situation in which different functions could be called without
    being able to know which one at compile time, used to use
    srand(time(0)); switch(rand() % 3). But recently it was changed to
    switch ((rand() >> 8) % 3) because "the ">> 8" (typically)
    improves the period of the lowest 2 bits".
    (And of course n % 3 depends on *all* of the bits of n, and the
    shift does nothing but worsen the bias due to RAND_MAX + 1 not
    being a multiple of 3.)
    </ot>
    --
    Army1987 (Replace "NOSPAM" with "email")
    No-one ever won a game by resigning. -- S. Tartakower
    Army1987, Aug 22, 2007
    #7
  8. Erik de Castro Lopo

    pete Guest

    Army1987 wrote:
    >
    > On Tue, 21 Aug 2007 15:04:57 -0400, Kenneth Brody wrote:
    >
    > > I took this as simply a sample snippet to demonstrate the "should
    > > 'r' be in scope for the 'while' statement" question, not as a
    > > real-life code snippet. We often post "useless" snippets of code
    > > here, simply to boil it down to the simplest wasy of demonstrating
    > > what we are asking.

    >
    > <ot>
    > In the comp.lang.c++ FAQ there is a snippet of code which, to show
    > a situation in which different functions could be called without
    > being able to know which one at compile time, used to use
    > srand(time(0)); switch(rand() % 3). But recently it was changed to
    > switch ((rand() >> 8) % 3) because "the ">> 8" (typically)
    > improves the period of the lowest 2 bits".
    > (And of course n % 3 depends on *all* of the bits of n, and the
    > shift does nothing but worsen the bias due to RAND_MAX + 1 not
    > being a multiple of 3.)
    > </ot>


    They were probably thinking of (n % 4) and got confused.

    --
    pete
    pete, Aug 22, 2007
    #8
  9. pete wrote:
    >
    > Army1987 wrote:

    [...]
    > > <ot>
    > > In the comp.lang.c++ FAQ there is a snippet of code which, to show
    > > a situation in which different functions could be called without
    > > being able to know which one at compile time, used to use
    > > srand(time(0)); switch(rand() % 3). But recently it was changed to
    > > switch ((rand() >> 8) % 3) because "the ">> 8" (typically)
    > > improves the period of the lowest 2 bits".
    > > (And of course n % 3 depends on *all* of the bits of n, and the
    > > shift does nothing but worsen the bias due to RAND_MAX + 1 not
    > > being a multiple of 3.)
    > > </ot>

    >
    > They were probably thinking of (n % 4) and got confused.


    Or (n & 3).

    --
    +-------------------------+--------------------+-----------------------+
    | Kenneth J. Brody | www.hvcomputer.com | #include |
    | kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------+
    Don't e-mail me at: <mailto:>
    Kenneth Brody, Aug 22, 2007
    #9
    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. Jon

    app vars and cache vars

    Jon, Dec 14, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    378
  2. Steven

    while loop in a while loop

    Steven, Mar 24, 2005, in forum: Java
    Replies:
    5
    Views:
    2,213
    Tim Slattery
    Mar 30, 2005
  3. Uday Bidkar
    Replies:
    4
    Views:
    474
    =?ISO-8859-15?Q?Juli=E1n?= Albo
    Dec 12, 2006
  4. Linuxguy123
    Replies:
    7
    Views:
    664
    Paddy O'Loughlin
    Feb 20, 2009
  5. Isaac Won
    Replies:
    9
    Views:
    349
    Ulrich Eckhardt
    Mar 4, 2013
Loading...

Share This Page