OSDev.org

Kevin wrote:It's a pretty common way of how programming languages work. In most of them you can shadow global variables with local ones. Off the top of my head I can't name a single one which supports different scopes and doesn't allow it.

Neither D nor C# allow this particular construct.

Regards,
John.

When you use functions, especially in libraries, it is fairly obvious why you might want to reuse variable names in an inner scope. I personally wouldn't do so in quite the manner done in your example within a single function, but at least it is very visible there.

Perhaps the language designers just thought it was easier to produce compilers that didn't have to reject such use of local variables. It's not something that has caught me out in many years of programming, unlike some of Cs other little snares.

iansjack wrote:When you use functions, especially in libraries, it is fairly obvious why you might want to reuse variable names in an inner scope. I personally wouldn't do so in quite the manner done in your example within a single function, but at least it is very visible there.

Perhaps the language designers just thought it was easier to produce compilers that didn't have to reject such use of local variables. It's not something that has caught me out in many years of programming, unlike some of Cs other little snares.

Its not something I have ever noticed before, despite reasonably extensive experience with C, which is why I was suprised to see it accept it. Actually the bug in my code was slightly less obvious that the example provided, which was just a simplistic reduction of the problem (I had a construct like for(uint32_t i = 0; (i < cluster_size) && (ptr < buf_size); i++, ptr++) or something similar and then a for(int i = 0; i < ...; i++) nested somewhere inside it as part of a fat driver).

I would have thought, however, that it is easier to design a compiler that rejects this redefinition rather than writing extra code which has to decide which version of 'i' to update at each point?

Regards,
John.

Personally I feel that declaring the variable within the for loop in this way is likely to lead to this sort of error. (Although it's not an error as such. The code is doing what it is asked to, it's just not necessarily what the programmer intended.) The same really holds with declaring variables anywhere in the middle of a program. I prefer to declare them all at the start of a function or block. But that's just a style that works for me.

To OP: You can turn on warning about shadow variables on gcc and prevent this kind of mistake happen again.

jnc100 wrote:I would have thought, however, that it is easier to design a compiler that rejects this redefinition rather than writing extra code which has to decide which version of 'i' to update at each point?

Supporting it this way needs no extra code apart from your regular scope and frame allocation. Catching the duplicate variable name reused in an inner scope requires adding a scan of all the outer scopes for the same variable name.

since u guyz good with style mby u can review my code ???? is c89 so easy to compile with gcc compilers

Love4Boobies wrote:since u guyz good with style mby u can review my code ???? is c89 so easy to compile with gcc compilers

It is c99, so no. (Or c89 with 1994 amendment, which makes it not exactly c89).

@Love4Boobies:

Copying tutorials blindly can be a little misleading. You should contact the author of this fine C tutorial, Jack Aplin.

You should also note, for further reference, that reproducing a work without reproducing the copyright notice is an action that may lay you open to litigation.

Copyright (c) 1985, Landon Curt Noll & Larry Bassel.
All Rights Reserved. Permission for personal, educational or non-profit use is
granted provided this this copyright and notice are included in its entirety
and remains unaltered. All other uses must receive prior permission in writing
from both Landon Curt Noll and Larry Bassel.

dozniak wrote:It is c99, so no. (Or c89 with 1994 amendment, which makes it not exactly c89).

Not as far as I can tell. Which post-C89 constructs do you see?

iansjack wrote:Copying tutorials blindly can be a little misleading.

What tutorial?

iansjack wrote:You should contact the author of this fine C tutorial, Jack Aplin.

I haven't heard of this person before. The program I've pasted seems to be a variation of his:

• It includes the appropriate header.
• It takes advantage of the fact that a and i[a] mean the same thing.
• It uses digraphs for obfuscation.
• It returns 0, which C89 does not do by default (unlike C99).
• It doesn't come with other files.
• It prints "hello, world!\n" rather than "Hello, world!\n".

Interesting find.

Which post-C89 constructs do you see?

wikipedia wrote:In 1994 a normative amendment to the C standard, included in C99, supplied digraphs as more readable alternatives to five of the trigraphs. They are:

Code: Select all

Digraph 	Equivalent
<:         [
:>         ]
<%         {
%>         }
%:         #

D'oh! The answer was in my own reply, only a few lines below. Thanks.

Actually, on my 64-bit Gentoo system both programs compiled but only printed the initial "h" (or "H") and then segfaulted. One day when I'm really bored I may debug it to see why. I tried running splint on it; for some reason it didn't like it!