What a stupid gcc!

[zgene]

Look at this code:

1. #include<stdio.h>
2.
3. main()
4. { const int *pc;
5. int i = 10;
6.
7. pc = &i;
8. printf("%d\n", *pc);
9.
10. int c = 2;
11. pc = &c;
12. printf("%d\n", *pc);
13. }

If I compile this code with gcc, I get:

myprompt> gcc PtrTest.c
PtrTest.c: In function `main':
PtrTest.c:9: parse error before `int'
PtrTest.c:10: `c' undeclared (first use in this function)
PtrTest.c:10: (Each undeclared identifier is reported only once
PtrTest.c:10: for each function it appears in.)
myprompt>

Whereas g++ compiles it nicely. Look:

myprompt> g++ PtrTest.c
myprompt>

However, if I move Line 10 to Line 6, gcc also compiles it nicely.

So, does g want us to declare all variables at the head of a block? What
a stupid gcc!

 

[James Kuyper]

Look at this code:

1. #include<stdio.h>
2.
3. main()
4. { const int *pc;
5. int i = 10;
6.
7. pc = &i;
8. printf("%d\n", *pc);
9.
10. int c = 2;
11. pc = &c;
12. printf("%d\n", *pc);
13. }

If I compile this code with gcc, I get:

myprompt> gcc PtrTest.c
PtrTest.c: In function `main':
PtrTest.c:9: parse error before `int'
PtrTest.c:10: `c' undeclared (first use in this function)
PtrTest.c:10: (Each undeclared identifier is reported only once
PtrTest.c:10: for each function it appears in.)
myprompt>

Whereas g++ compiles it nicely. Look:

myprompt> g++ PtrTest.c
myprompt>

However, if I move Line 10 to Line 6, gcc also compiles it nicely.

So, does g want us to declare all variables at the head of a block? What
a stupid gcc!

Be more careful with the "stupid" label - it lacks historical
perspective. Do you do everything right the first time? Would you care
to be judged right now based upon how well you did something when you
were only 1/3 of your current age?

By default, gcc compiles gnu89, a language of it's own closely related
to C89. The ability to intermix declarations and statements that was
present in C++ almost from the beginning, was not added to C until C99,
and it was added to GnuC at around the same time. To put gcc into gnu99
or C99 mode, use the options -std=gnu99 or -std=c99, respectively.

C99 has had a very slow adoption rate; unlike C89, it had no strong
compelling advantage over existing versions of C (the feature whose
absence you're complaining about is one of the less compelling ones),
and some of it's new features were unpopular with many people. That's
why gnu89 is still the default, and why -ansi is equivalent to -std=c89.

 

[Eric Sosman]

[...]
So, does g want us to declare all variables at the head of a block? What
a stupid gcc!

Any compiler conforming to the original "C90" ANSI Standard must
insist that all declarations precede all statements within a block.
It's a requirement of that edition of the C language.

The 1999 revision of the Standard ("C99") relaxed the requirement:
Statements and declarations can be intermixed freely, provided each
identifier's declaration precedes its first use.

The gcc compilers, like many others, can deal with code written
for either version of the Standard, and a few can even handle the
still later edition of 2011 ("C11"). The only requirement is that
the user invoke the compiler properly, telling it what dialect of C
it is supposed to adhere to. The documentation accompanying gcc
describes (quite clearly) how this is done, and what dialect is
chosen if you do not specify one (as you did not).

gcc cannot read your mind. What a stupid gcc!

 

[Jens Thoms Toerring]

Look at this code:

1. #include<stdio.h>
2.
3. main()
4. { const int *pc;
5. int i = 10;
6.
7. pc = &i;
8. printf("%d\n", *pc);
9.
10. int c = 2;
11. pc = &c;
12. printf("%d\n", *pc);
13. }

If I compile this code with gcc, I get:

myprompt> gcc PtrTest.c
PtrTest.c: In function `main':
PtrTest.c:9: parse error before `int'
PtrTest.c:10: `c' undeclared (first use in this function)
PtrTest.c:10: (Each undeclared identifier is reported only once
PtrTest.c:10: for each function it appears in.)
myprompt>

Whereas g++ compiles it nicely. Look:

myprompt> g++ PtrTest.c
myprompt>

However, if I move Line 10 to Line 6, gcc also compiles it nicely.

So, does g want us to declare all variables at the head of a block? What
a stupid gcc!

You must either be using a very old version of gcc or 'gcc' is
an alias or similar that enforces C89 compatibility - in C89 you
definitely have to define all variables before the first "execu-
table" line. My version of gcc (4.6.1.) doesn't issue any war-
nings for your program when no options are set and several (but
different from yours) warnings when setting options for C89-
compatibility and/or a higher warning level.

g++ does compile a different language than C so it might accept
programs that gcc doesn't, so its similar to complaining that
your cars sinks when you drive it into a river while your boot
does swim.
Regards, Jens

 

[Joe Pfeiffer]

Look at this code:

1. #include<stdio.h>
2.
3. main()
4. { const int *pc;
5. int i = 10;
6.
7. pc = &i;
8. printf("%d\n", *pc);
9.
10. int c = 2;
11. pc = &c;
12. printf("%d\n", *pc);
13. }

If I compile this code with gcc, I get:

myprompt> gcc PtrTest.c
PtrTest.c: In function `main':
PtrTest.c:9: parse error before `int'
PtrTest.c:10: `c' undeclared (first use in this function)
PtrTest.c:10: (Each undeclared identifier is reported only once
PtrTest.c:10: for each function it appears in.)
myprompt>

Whereas g++ compiles it nicely. Look:

myprompt> g++ PtrTest.c
myprompt>

However, if I move Line 10 to Line 6, gcc also compiles it nicely.

So, does g want us to declare all variables at the head of a block? What
a stupid gcc!

When you tell it to compile C, it compiles C (admittedly, as others have
pointed out, an old version of the standard). When you tell it to
compile C++, it compiles C++. I fail to see the grounds for your
complaint.

 

[Nick Bowler]

1. #include<stdio.h>
2.
3. main()

Here, we have an example of the so-called "implicit int" in this
declaration of main.

4. { const int *pc;
5. int i = 10;
6.
7. pc = &i;
8. printf("%d\n", *pc);
9.
10. int c = 2;

And here, we have an example of the so-called "mixed declarations and
statements" with this declaration of c.

11. pc = &c;
12. printf("%d\n", *pc);
13. }

"Mixed declarations and statements" were supported starting with the
1999 revision of the C standard. "Implicit int" ceased being supported
as of the very same revision. There is therefore no revision of the C
standard for which the above is valid. What a stupid program!

 

[Rui Maciel]

You must either be using a very old version of gcc or 'gcc' is
an alias or similar that enforces C89 compatibility - in C89 you
definitely have to define all variables before the first "execu-
table" line. My version of gcc (4.6.1.) doesn't issue any war-
nings for your program when no options are set and several (but
different from yours) warnings when setting options for C89-
compatibility and/or a higher warning level.

Quite true. With gcc 4.6.3, the "forbids mixed declaration and code"
message is only presented as a warning when explicitly compiling the code
according to the C89/C90 standard, and only if the -pedantic flag is passed.


Rui Maciel

 

[Varun Tewari]

Look at this code:

1. #include<stdio.h>
2.
3. main()
4. { const int *pc;
5. int i = 10;
6.
7. pc = &i;
8. printf("%d\n", *pc);
9.
10. int c = 2;
11. pc = &c;
12. printf("%d\n", *pc);
13. }

If I compile this code with gcc, I get:

myprompt> gcc PtrTest.c
PtrTest.c: In function `main':
PtrTest.c:9: parse error before `int'
PtrTest.c:10: `c' undeclared (first use in this function)
PtrTest.c:10: (Each undeclared identifier is reported only once
PtrTest.c:10: for each function it appears in.)
myprompt>

Whereas g++ compiles it nicely. Look:

myprompt> g++ PtrTest.c
myprompt>

However, if I move Line 10 to Line 6, gcc also compiles it nicely.

So, does g want us to declare all variables at the head of a block? What
a stupid gcc!

Its simply not stupid, its a simple fact the C++/Java allow decalaration anywhere in the code, but C wants them the first thing when you code. That's all

 

[James Kuyper]

On 06/14/2012 06:14 AM, Varun Tewari wrote:
....

Its simply not stupid, its a simple fact the C++/Java allow decalaration anywhere in the code, but C wants them the first thing when you code. That's all

That's not been true for C since C99; we're already up to C2011.

 

[Noob]

By default, gcc compiles gnu89, a language of it's own closely related
to C89. The ability to intermix declarations and statements that was
present in C++ almost from the beginning, was not added to C until C99,
and it was added to GnuC at around the same time. To put gcc into gnu99
or C99 mode, use the options -std=gnu99 or -std=c99, respectively.

James,

(I've snipped the OP's rant, because trolls deserve to be ignored.)

Please note that gnu89, the default mode, does allow mixed
declarations and code.

http://gcc.gnu.org/onlinedocs/gcc/Mixed-Declarations.html

$ cat mix.c
int main(void)
{
int a = 5;
a += 3;

int b = 2;
b += 1;

return a + b;
}

$ gcc -Wall -Wextra -std=gnu89 mix.c

No warning.

 

[Nomen Nescio]

James,

(I've snipped the OP's rant, because trolls deserve to be ignored.)

Please note that gnu89, the default mode, does allow mixed
declarations and code.

http://gcc.gnu.org/onlinedocs/gcc/Mixed-Declarations.html

$ cat mix.c
int main(void)
{
int a = 5;
a += 3;

int b = 2;
b += 1;

return a + b;
}

$ gcc -Wall -Wextra -std=gnu89 mix.c

No warning.

Yes, we know. With enough switches gcc will compile anything. The question
is, how long will K&R C and unsafe defaults be gcc's default mode.

Hello clang, bye bye gcc!

 

[Rui Maciel]

Quite true. With gcc 4.6.3, the "forbids mixed declaration and code"
message is only presented as a warning when explicitly compiling the code
according to the C89/C90 standard, and only if the -pedantic flag is
passed.

Just for posterity.

<example>
rui@Kubuntu:tmp$ cat main.c
#include<stdio.h>

main()
{
const int *pc;
int i = 10;

pc = &i;
printf("%d\n", *pc);

int c = 2;
pc = &c;
printf("%d\n", *pc);
}
rui@Kubuntu:tmp$ gcc -std=c90 -Wall -pedantic main.c
main.c:3:1: warning: return type defaults to ‘int’ [-Wreturn-type]
main.c: In function ‘main’:
main.c:11:2: warning: ISO C90 forbids mixed declarations and code [-
pedantic]
main.c:14:1: warning: control reaches end of non-void function [-Wreturn-
type]
rui@Kubuntu:tmp$ gcc -std=c99 -Wall -pedantic main.c
main.c:3:1: warning: return type defaults to ‘int’ [enabled by default]
</example>


Rui Maciel

 

[Rui Maciel]

Yes, we know. With enough switches gcc will compile anything. The question
is, how long will K&R C and unsafe defaults be gcc's default mode.

Hello clang, bye bye gcc!

There might be a ton of issues which would make clang a preferable option
over gcc, but the default config values of a specific set of options is
clearly not one.


Rui Maciel

 

[Noob]

Yes, we know. With enough switches gcc will compile anything. The question
is, how long will K&R C and unsafe defaults be gcc's default mode.

GCC's default mode is not K&R C, it's C90 with extensions.

Thanks for trolling.

Hello clang, bye bye gcc!

Competition is good.

 

[Kaz Kylheku]

So, does g want us to declare all variables at the head of a block? What
a stupid gcc!

Stupid you for disparaging a tool which translates a family of languages you
haven't studied properly.

 

[Jorgen Grahn]

Its simply not stupid, its a simple fact the C++/Java allow
decalaration anywhere in the code, but C wants them the first thing
when you code. That's all

You could say that "declarations only at the start of block" was a
stupid design ... I'm very happy this got changed, and it should
probably have happened earlier, when 'const' and such things were
introduced.

Now all that remains is to educate the users. Most code I read
doesn't even use the C89 "at the start of block" rule. It lumps all
the variables at the start of the function -- even those that are only
used and only make sense inside some loop, two pages down ...

/Jorgen

 

[BartC]

You could say that "declarations only at the start of block" was a
stupid design ... I'm very happy this got changed, and it should
probably have happened earlier, when 'const' and such things were
introduced.

Now all that remains is to educate the users. Most code I read
doesn't even use the C89 "at the start of block" rule. It lumps all
the variables at the start of the function -- even those that are only
used and only make sense inside some loop, two pages down ...

But what happens when the code defines a variable two pages into a function,
but you happen to be reading some code using that same variable four pages
into the function! Where do you go to find the definition? At the start of a
function is usually a good place! You don't always know that a variable is
only used once.

And with blocks having their own scope (?) the same name can be used more
than once with different definitions; even more confusing.

 

[James Kuyper]

But what happens when the code defines a variable two pages into a function,
but you happen to be reading some code using that same variable four pages
into the function! Where do you go to find the definition?

Backwards from the point of use, until I find a definition. It's the
only safe direction to look, and I'll get to the definition a lot
quicker that way if it's closer to the point of use.

... At the start of a
function is usually a good place! You don't always know that a variable is
only used once.

I find it quite easy to determine that; usually during design,
definitely by the time I've finished coding. The future reader doesn't
need to know this in order to perform his search, just search backwards
from the point of use.

And with blocks having their own scope (?) ...
Correct.

... the same name can be used more
than once with different definitions; even more confusing.

Yes, shadowing definitions can be confusing, but different blocks of
code using the same variable name for different purposes is even more
confusing when that name names the same variable. which is a commonplace
consequence of defining things only at the top of the block.

 

[Rui Maciel]

But what happens when the code defines a variable two pages into a
function, but you happen to be reading some code using that same variable
four pages into the function! Where do you go to find the definition? At
the start of a function is usually a good place! You don't always know
that a variable is only used once.

And with blocks having their own scope (?) the same name can be used more
than once with different definitions; even more confusing.

Why not let the text editor handle this? Wouldn't a simple backward search
for a identifier be enough to handle both these cases? Some text editors
even provide a way to run backward searches for the keyword currently under
the text cursor. For example, with vim it's only a matter of placing the
cursor over an identifier and hitting #.


Rui Maciel

 

[Joe Pfeiffer]

You could say that "declarations only at the start of block" was a
stupid design ... I'm very happy this got changed, and it should
probably have happened earlier, when 'const' and such things were
introduced.

Now all that remains is to educate the users. Most code I read
doesn't even use the C89 "at the start of block" rule. It lumps all
the variables at the start of the function -- even those that are only
used and only make sense inside some loop, two pages down ...

/Jorgen

It may be a sign of my age and when I learned C, but I really like
defining all my variables, and then using them. If defining a variable
at the start of a block other than the start of the function (and not as
the iterator of a for loop) makes sense, it's a really good clue my
function is too long.

If my variables are first used two pages down, the function is almost
certainly too long. If "two pages down" is even a relevant phrase, my
function is almost certainly too long.