Why is this code compiling properly??

[onkar]

#include<stdio.h>
int i;
int i;
int main(){
printf("i=%d\n",i);
return 0;
}

Note : I am using gcc-3.4.3 on i386-redhat-linux

 

[Chris Dollin]

onkar wrote:

(Please put your question in the message body, not just
lonely as a cloud in the subject line.)#

Why is this code compiling properly??

#include<stdio.h>
int i;
int i;
int main(){
printf("i=%d\n",i);
return 0;
}

Note : I am using gcc-3.4.3 on i386-redhat-linux

Why shouldn't it?

 

[sandy]

onkar wrote:

(Please put your question in the message body, not just
lonely as a cloud in the subject line.)#

As both the variables are uninitialized, thats why the code is
compiling properly.
If you try the same thing with atleast one of them being initialised
with some value, then surely your code will not compile.

Cheers,
SandeepKsinha.

 

[sam_cit]

As both the variables are uninitialized, thats why the code is
compiling properly.
If you try the same thing with atleast one of them being initialised
with some value, then surely your code will not compile.

Cheers,
SandeepKsinha.

only one initialize doesn't give any error, both have to be
initialized for the compiler to give the error.

 

[Mark McIntyre]

.... but it is broken ,since he attempts to print the value of an
uninitialised variable. This is likely to crash or print garbage.
Don't do that...

only one initialize doesn't give any error, both have to be
initialized for the compiler to give the error.

The lines
int i;
int i;

at file scope are both declarations. They are also /tentative/
definitions, that is to say, they are potentially going to be used to
define i, if needed.

Since neither is initialised, the compiler doesn't have a /form
definition/ yet. If the compiler doesn't find a firm definition of i
in the same file, it takes one of the declarations and uses it as a
definition. In this case it defines i to be an int with unspecified
value.

If you initialise one of the declarations with a value, it becomes a
definition. Thats ok.

You can have only one definition, so if you initialise them both, it
is an error.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

sandy said:

As both the variables are uninitialized, thats why the code is
compiling properly.

Not so. One of them can be initialised and the code will still be fine.

If you try the same thing with atleast one of them being initialised
with some value, then surely your code will not compile.

Not so. One of them can be initialised and the code will still be fine.

Please do not give incorrect advice on comp.lang.c. Thank you.

 

[Random832]

... but it is broken ,since he attempts to print the value of an
uninitialised variable. This is likely to crash or print garbage.

No it's not. Though the use of the term uninitialized is problematic,
you seem to know what he meant by it, and there _is_ a tradition on some
systems of using it to refer to any such data [OT: bss section, zero-bit
floats and NULLs, and all that]

 

[CBFalconer]

... but it is broken ,since he attempts to print the value of an
uninitialised variable. This is likely to crash or print garbage.

No it's not. Though the use of the term uninitialized is problematic,
you seem to know what he meant by it, and there _is_ a tradition on
some systems of using it to refer to any such data [OT: bss section,
zero-bit floats and NULLs, and all that]

Yes it is. Accessing an uninitialized variable invokes undefined
behaviour, which can often be a crash.

 

[Chris Dollin]

... but it is broken ,since he attempts to print the value of an
uninitialised variable. This is likely to crash or print garbage.
Don't do that...
(fx:snip)

Since neither is initialised, the compiler doesn't have a /form
definition/ yet. If the compiler doesn't find a firm definition of i
in the same file, it takes one of the declarations and uses it as a
definition. In this case it defines i to be an int with unspecified
value.

Surely zero, since it's a static variable with no explicit initialisation.

["static" as in "not automatic, not mallocated", rather than as in
"scope local to file."]

 

[Keith Thompson]

sandy said:

Not so. One of them can be initialised and the code will still be fine.


Not so. One of them can be initialised and the code will still be fine.

Please do not give incorrect advice on comp.lang.c. Thank you.

To interpret sandy's explanation charitably:

Both variables are uninitialized (more precisely, not explicitly
initialized). That's why the code is legal.

If one of them were uninitialized and the other were explicitly
initialized, *that* would be why the code is legal.

 

[Richard Heathfield]

Keith Thompson said:

To interpret sandy's explanation charitably:

Both variables are uninitialized (more precisely, not explicitly
initialized). That's why the code is legal.

If one of them were uninitialized and the other were explicitly
initialized, *that* would be why the code is legal.

But he said (and the quote remains, above): "If you try the same thing with
atleast one of them being initialised with some value, then surely your
code will not compile." That is simply wrong.

 

[Keith Thompson]

Keith Thompson said: [...]

To interpret sandy's explanation charitably:

Both variables are uninitialized (more precisely, not explicitly
initialized). That's why the code is legal.

If one of them were uninitialized and the other were explicitly
initialized, *that* would be why the code is legal.

But he said (and the quote remains, above): "If you try the same thing with
atleast one of them being initialised with some value, then surely your
code will not compile." That is simply wrong.

You're right; I should have paid more attention.

 

[Keith Thompson]

(e-mail address removed) wrote:

As both the variables are uninitialized, thats why the code is
compiling properly.

... but it is broken ,since he attempts to print the value of an
uninitialised variable. This is likely to crash or print garbage.

No it's not. Though the use of the term uninitialized is problematic,
you seem to know what he meant by it, and there _is_ a tradition on
some systems of using it to refer to any such data [OT: bss section,
zero-bit floats and NULLs, and all that]

Yes it is. Accessing an uninitialized variable invokes undefined
behaviour, which can often be a crash.

Yes, but the code in question:

#include<stdio.h>
int i;
int i;
int main(){
printf("i=%d\n",i);
return 0;
}

does not access an uninitialized variable. Since i has static storage
duration, it's implicitly initialized to zero.

 

[Random832]

Mark McIntyre wrote:
(e-mail address removed) wrote:

As both the variables are uninitialized, thats why the code is
compiling properly.

... but it is broken ,since he attempts to print the value of an
uninitialised variable. This is likely to crash or print garbage.

No it's not. Though the use of the term uninitialized is problematic,
you seem to know what he meant by it, and there _is_ a tradition on
some systems of using it to refer to any such data [OT: bss section,
zero-bit floats and NULLs, and all that]

Yes it is. Accessing an uninitialized variable invokes undefined
behaviour, which can often be a crash.

Yes, but the code in question: [...]
does not access an uninitialized variable. Since i has static storage
duration, it's implicitly initialized to zero.

The term "uninitialized" is often used to refer to variables in this
state. We're all using it. Even he used it elsewhere in the same post.
He's just being disingenuous.

 

[jaysome]

#include<stdio.h>
int i;
int i;
int main(){
printf("i=%d\n",i);
return 0;
}

Note : I am using gcc-3.4.3 on i386-redhat-linux

I think you're missing a compiler option. Try this, assuming the name
of your source file is foo.c:

gcc -W,-runPClint -o foo foo.c

foo.c(3) : Error 31: Redefinition of symbol 'i' compare with line 2

Works for me.

 

[Richard Heathfield]

jaysome said:

I think you're missing a compiler option. Try this, assuming the name
of your source file is foo.c:

gcc -W,-runPClint -o foo foo.c

foo.c(3) : Error 31: Redefinition of symbol 'i' compare with line 2

Works for me.

Fails for you, you mean. Your compiler doesn't understand about tentative
definitions.

 

[Richard Heathfield]

Mark McIntyre said:

... but it is broken ,since he attempts to print the value of an
uninitialised variable.

No, he isn't. Whilst there is no *explicit* initialisation, the object is at
file scope and thus takes on the appropriate default static initialiser
value, which in this case is 0.

Since neither is initialised, the compiler doesn't have a /form
definition/ yet. If the compiler doesn't find a firm definition of i
in the same file, it takes one of the declarations and uses it as a
definition. In this case it defines i to be an int with unspecified
value.

Wrong.

 

[MJ_India]

#include<stdio.h>
int i;
int i;
int main(){
printf("i=%d\n",i);
return 0;
}

Note : I am using gcc-3.4.3 on i386-redhat-linux

It takes one as (extern) declaration and the other as definition. When
it doesn't get any definition (i.e. initialized) and all declarations,
it picks one as uninitialized definition.

If you compile the program as gcc -S foo.c (assume your code is foo.c)
you will get the following code (on my red hat linux pentium machine)
======================================
.file "foo.c"
.section .rodata
..LC0:
.string "i=%d\n"
. . . .
/* Some code */
. . . .
..Lfe1:
.size main,.Lfe1-main
.comm i,4,4
.ident "GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"
======================================

If you check the lines .comm i, 4, 4
i is lodged just once in memory i.e. one of the line is considered as
declaration while other is definition.

So While linking it will look for symbol i in other object files (if
present), if it doesn't find one, it will keep one declaration as
definition.

To ensure this make a more file foo1.c

/* ================ foo1.c =================*/
int i = 2;
/* file ends */

Recompile the program "gcc foo.c foo1.c"
Execute the program "./a.out"

I'm sure output will be "i=2"

Cheers MJ

 

[Mark McIntyre]

Surely zero, since it's a static variable with no explicit initialisation.

yes, indeed. I overstated the case.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Mark McIntyre said:


No, he isn't. Whilst there is no *explicit* initialisation, the object is at
file scope and thus takes on the appropriate default static initialiser
value, which in this case is 0.

Yes, somehow I missed that it was file-scope when I wrote that bit. .

Wrong.

Well, aside from the unspecified part, I'm right. Either you need to
correct people usefully, or you need to stop correcting people. Who do
you think you are? Dan Pop?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan