do/while loop and scope of automatic vars

[Erik de Castro Lopo]

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

 

[Keith Thompson]

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

 

[Robert Gamble]

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

 

[Eric Sosman]

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

 

[CBFalconer]

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());

 

[Kenneth Brody]

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:[email protected]>

 

[Army1987]

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>

 

[pete]

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

 

[Kenneth Brody]

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:[email protected]>