Thread: Additional scope used with for loop/initializer variable when not using C99?

Originally Posted by MutantJohn

Then can I ask, what's gnu99? I compile with -std=gnu99. Is it logically equivalent to c99?

It is C99 with GNU extensions.

Tim S.

ANSI C is ambiguous, since technically C89 (C90), C99, and C11 are all ANSI standards. The prior defacto standard is K&R C, but it's ancient history.

The reason that declarations must go prior to statements in C89 is that in assembler, you want to reserve space for all stack variables at the start of the function, so the requirement helps compiler writers write simpler compilers. Clearly the C committee did not think that was sufficient reason to keep the feature in the years just prior to 1999.

Actually C89 is an ANSI standard, C90, C99, and C11 are ISO standards.

O_o

If you are going to be that picky, you are just as wrong; Standard C is a joint "ISO"/"IEC" standard.

In reality, C90 and C99 are indeed "ANSI" standards, ISO standards, and $(OTHER STANDARD BODY) standards. (The C11 standard will likely be adopted entirely by "ANSI".)

[Edit]
Just a "heads up": if a lesser body has adopted the same "ISO" standard, it can often be found cheaper than from "ISO" proper.
[/Edit]

I don't know why people still don't get this concept after all this time.

There are many standards bodies in the world.

Sometimes a national or other lesser standard body will establish a standard first--as in C89.

Sometimes the "International Standards Organization" will establish a standard first--as in C99.

For the most part, lesser standard bodies will adopt "ISO" standards with no change or minor changes--as in C99.

As often as not, the "ISO" will adopt established standards from lesser bodies, but sometimes changes are necessary for the sake of the international standard.

Soma

I did not know that C11 wasn't adopted by ANSI. Learned something new today.

Notice that if you compile with -Wshadow (on gcc, or whatever equivalent), your second code will produce a warning about the variable i being "shadowed", if there is another i in the blocks above it. This isn't a problem, but you just have to be careful with using "i" inside one of those blocks which, as the code gets larger and more complex, may well see you inadvertently using the for-loop variable instead of the slightly-more-global outer-block loop variable that you intended.

Thus, nesting another block like this is something to be wary of, but yes, basically equivalent. But is it really that much harder than just declaring the variable at the beginning? And do you really want to risk having two "i's" in nested blocks?

Personally, I declare where I first realise a variable is required. If it turns out to be confusing, conflicting or in any way sub-optimal, I move the declaration AND rename as necessary. You don't get performance gains from declaring variables earlier or later, just readability. And in modern UI's, the most readable way, I find, is to have declarations in a single block at the top of the functions so that readers can "skip" them while skimming, and yet know exactly where to find the definitions if they need them. Thus, I even tend to do:

Code:

int i;
for(i = 0; i < LIMIT; i++)
{
...
};

first (obviously compiles only as C99), then just shift the int i to the top of the block if required (i.e. moving to a non-C99 compiler, or to group declarations, etc.). I find the "in the for loop initialiser" declaration to be unnecessarily obscured when you're looking for declarations, and to be more difficult to cut/paste first time when you want to move it to the top of the block. But, as you can probably guess, that's more to do with ease of code management and saving myself a mis-click than any huge technical obstacle.

Sticking to strict C-89 style declarations solves the problem all round and works for everyone. Using C99-style declarations is convenient for the programmer only, not for anyone who reads the code later or is running on an older standard compiler. You solve one problem (where's the declaration for i?), which can be easily resolved in any modern UI, by replacing it with something that introduces other problems. But in the grand scheme of things, none of it matters much and it's all down to personal style.

You generally do want different loop indexes for nested loops, but using the C99 syntax can prevent related bugs. For instance:

Code:

for(int i=0;i<length;++i) {
  struct Example *container_of_stuff = do_stuff(i);
  for(int i=0;i<length_of_stuff;++i)
     use(container_of_stuff[i]);/*benign shadowing*/
  do_more_stuff(i) /*uses outer loop i, as intended*/
}

Putting the extra set of curly braces achieves the same thing, but it's not a common practice, so is likely to be forgotten.