Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #22223 > unrolled thread

What a stupid gcc!

Back to article view | Back to comp.lang.c

Contents

  What a stupid gcc! zgene <nospam@nospam.com> - 2012-06-13 21:41 +0000
    Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-13 18:01 -0400
      Re: What a stupid gcc! Noob <root@127.0.0.1> - 2012-06-14 13:00 +0200
        Re: What a stupid gcc! Nomen Nescio <nobody@dizum.com> - 2012-06-14 14:33 +0200
          Re: What a stupid gcc! Rui Maciel <rui.maciel@gmail.com> - 2012-06-14 14:46 +0100
          Re: What a stupid gcc! Noob <root@127.0.0.1> - 2012-06-14 18:19 +0200
    Re: What a stupid gcc! Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-06-13 18:06 -0400
    Re: What a stupid gcc! jt@toerring.de (Jens Thoms Toerring) - 2012-06-13 22:19 +0000
      Re: What a stupid gcc! Rui Maciel <rui.maciel@gmail.com> - 2012-06-14 09:47 +0100
        Re: What a stupid gcc! Rui Maciel <rui.maciel@gmail.com> - 2012-06-14 14:37 +0100
    Re: What a stupid gcc! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-06-13 17:05 -0600
    Re: What a stupid gcc! Nick Bowler <nbowler@draconx.ca> - 2012-06-14 00:09 +0000
    Re: What a stupid gcc! Varun Tewari <tewari.varun@gmail.com> - 2012-06-14 03:14 -0700
      Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-14 06:56 -0400
      Re: What a stupid gcc! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-17 07:18 +0000
        Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-17 11:47 +0100
          Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-17 09:31 -0400
            Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-18 12:34 +0100
              Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-18 08:18 -0400
                Re: What a stupid gcc! gwowen <gwowen@gmail.com> - 2012-06-18 05:42 -0700
                  Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-18 09:39 -0400
                Re: What a stupid gcc! Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-06-18 09:06 -0400
                  Re: What a stupid gcc! ImpalerCore <jadill33@gmail.com> - 2012-06-18 07:18 -0700
              Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-19 00:13 -0700
                Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 11:28 +0100
                  Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 07:30 -0400
                  Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-20 00:16 -0700
          Re: What a stupid gcc! Rui Maciel <rui.maciel@gmail.com> - 2012-06-17 15:52 +0100
          Re: What a stupid gcc! Noob <root@localhost> - 2012-06-18 09:07 +0200
          Re: What a stupid gcc! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-18 09:03 +0000
          Re: What a stupid gcc! Andrew Smallshaw <andrews@sdf.lonestar.org> - 2012-06-18 16:02 +0000
            Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-18 19:40 +0100
              Re: What a stupid gcc! Noob <root@localhost> - 2012-06-18 23:52 +0200
              Re: What a stupid gcc! Ike Naar <ike@iceland.freeshell.org> - 2012-06-18 23:09 +0000
                Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 01:30 +0100
                  Re: What a stupid gcc! Ian Collins <ian-news@hotmail.com> - 2012-06-19 13:03 +1200
                    Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 06:34 -0400
                  Re: What a stupid gcc! Ike Naar <ike@sverige.freeshell.org> - 2012-06-19 08:43 +0000
                    Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 11:00 +0100
                      Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 07:05 -0400
                      Re: What a stupid gcc! Ian Collins <ian-news@hotmail.com> - 2012-06-19 23:21 +1200
                        Re: What a stupid gcc! Ian Collins <ian-news@hotmail.com> - 2012-06-19 23:22 +1200
                      Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-19 13:45 +0100
                        Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 15:23 +0100
                          Re: What a stupid gcc! Ike Naar <ike@iceland.freeshell.org> - 2012-06-19 16:14 +0000
                            Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 18:01 +0100
                              Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 13:59 -0400
                              Re: What a stupid gcc! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-06-19 15:29 -0600
                          Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-19 18:22 +0100
                            Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-19 21:13 +0100
                              Re: What a stupid gcc! Lew Pitcher <lpitcher@teksavvy.com> - 2012-06-19 16:27 -0400
                              Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 16:38 -0400
                                Re: What a stupid gcc! Kenneth Brody <kenbrody@spamcop.net> - 2012-06-20 09:47 -0400
                              Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-19 22:44 +0100
                                Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-21 01:39 -0700
                                  Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-21 10:55 +0100
                                    Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-21 04:11 -0700
                                      Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-21 12:36 +0100
                                        Re: What a stupid gcc! David Brown <david@westcontrol.removethisbit.com> - 2012-06-21 15:33 +0200
                                    Re: What a stupid gcc! Andrew Smallshaw <andrews@sdf.lonestar.org> - 2012-06-21 14:15 +0000
                              Re: What a stupid gcc! Kenneth Brody <kenbrody@spamcop.net> - 2012-06-20 09:37 -0400
                                Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-20 14:54 +0100
                                  Re: What a stupid gcc! Kenneth Brody <kenbrody@spamcop.net> - 2012-06-20 18:19 -0400
                                    Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-21 00:13 +0100
                                      Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-21 02:09 +0100
                                        Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-21 02:05 -0700
                                        Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-21 11:49 +0100
                                          Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-21 14:24 +0100
                                          Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-22 00:38 -0700
                                            Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-22 13:37 +0100
                                      Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-21 01:57 -0700
                                        Re: What a stupid gcc! "BartC" <bc@freeuk.com> - 2012-06-21 11:46 +0100
                                      Re: What a stupid gcc! Kenneth Brody <kenbrody@spamcop.net> - 2012-06-21 14:37 -0400
                                        Re: What a stupid gcc! Andrew Smallshaw <andrews@sdf.lonestar.org> - 2012-06-21 19:38 +0000
                                  Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-21 01:41 -0700
                                    Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-21 12:28 +0100
                Re: What a stupid gcc! Kaz Kylheku <kaz@kylheku.com> - 2012-06-19 15:05 +0000
          Re: What a stupid gcc! Ian Collins <ian-news@hotmail.com> - 2012-06-19 09:37 +1200
            Re: What a stupid gcc! ImpalerCore <jadill33@gmail.com> - 2012-06-18 15:18 -0700
            Re: What a stupid gcc! Paul J Gans <gansno@panix.com> - 2012-06-18 23:21 +0000
              Re: What a stupid gcc! Ian Collins <ian-news@hotmail.com> - 2012-06-19 11:26 +1200
                Re: What a stupid gcc! Paul J Gans <gansno@panix.com> - 2012-06-19 01:46 +0000
                  Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 07:19 -0400
                  Re: What a stupid gcc! Stephen Sprunk <stephen@sprunk.org> - 2012-06-19 08:01 -0500
                  Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 09:25 -0400
                    Re: What a stupid gcc! Les Cargill <lcargill99@comcast.com> - 2012-06-19 12:57 -0500
                      Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-19 14:59 -0400
              Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-19 01:36 +0100
                Re: What a stupid gcc! Paul J Gans <gansno@panix.com> - 2012-06-19 01:48 +0000
            Re: What a stupid gcc! Les Cargill <lcargill99@comcast.com> - 2012-06-18 19:50 -0500
            Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-19 00:19 -0700
              Re: What a stupid gcc! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-06-19 12:56 +0100
                Re: What a stupid gcc! nick_keighley_nospam@hotmail.com - 2012-06-20 00:26 -0700
                  Re: What a stupid gcc! James Kuyper <jameskuyper@verizon.net> - 2012-06-20 06:31 -0400
        Re: What a stupid gcc! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-06-18 00:18 -0600
          Re: What a stupid gcc! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-06-18 09:15 +0000
    Re: What a stupid gcc! Kaz Kylheku <kaz@kylheku.com> - 2012-06-14 23:21 +0000

Page 1 of 5  [1] 2 3 4 5  Next page →

#22223 — What a stupid gcc!

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!

[toc] | [next] | [standalone]

#22226

On 06/13/2012 05:41 PM, zgene wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#22253

James Kuyper wrote:

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

[toc] | [prev] | [next] | [standalone]

#22257

Noob <root@127.0.0.1> wrote:

> James Kuyper wrote:
> 
> > 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.

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!

[toc] | [prev] | [next] | [standalone]

#22263

Nomen Nescio wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#22268

Nomen Nescio wrote:

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

[toc] | [prev] | [next] | [standalone]

#22227

On 6/13/2012 5:41 PM, zgene wrote:
>[...]
> 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!

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#22228

zgene <nospam@nospam.com> wrote:
> 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
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#22248

Jens Thoms Toerring wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#22262

Rui Maciel wrote:

> Jens Thoms Toerring wrote:
> 
>> 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.

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

[toc] | [prev] | [next] | [standalone]

#22233

zgene <nospam@nospam.com> writes:

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

[toc] | [prev] | [next] | [standalone]

#22238

On Wed, 13 Jun 2012 21:41:53 +0000, zgene wrote:
> 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!

[toc] | [prev] | [next] | [standalone]

#22250

On Thursday, 14 June 2012 03:11:53 UTC+5:30, zgene  wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#22252

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

[toc] | [prev] | [next] | [standalone]

#22328

On Thu, 2012-06-14, 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

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

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#22331

"Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
news:slrnjtr16f.rk7.grahn+nntp@frailea.sa.invalid...
> On Thu, 2012-06-14, 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
>
> 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.


-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#22333

On 06/17/2012 06:47 AM, BartC wrote:
> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
> news:slrnjtr16f.rk7.grahn+nntp@frailea.sa.invalid...
...
>> 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?

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

[toc] | [prev] | [next] | [standalone]

#22359

"James Kuyper" <jameskuyper@verizon.net> wrote in message
news:jrkm86$43k$1@dont-email.me...
> On 06/17/2012 06:47 AM, BartC wrote:
>> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
>> news:slrnjtr16f.rk7.grahn+nntp@frailea.sa.invalid...
> ...
>>> 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?
>
> 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.

That means looking at every line of code before that point, for a variable
name that be similar to many others. Declarations at the start of a function
are easier for low-tech editors (even with one that can't switch quickly 
between two locations, probably you can run two instances of it).

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

Look at this example from the middle of a function (from Python sources):

      mz = z->ob_type->tp_as_number;

Applying a local declaration, and let's say you're lucky and this the first
use of mz you see, it might look like:

     PyNumberMethods mz = z->ob_type->tp_as_number;

That's great; we know what mz is. Except that's not the full picture. The mz
variable is actually declared like this at the top of the function:

        PyNumberMethods *mv, *mw, *mz;

Now we know there are three related variables, and there aren't any called
mx or my. Which can give an extra dimension to our knowledge (there are
parameters v, w, z, and mv, mw, and mz presumably correspond to these). It
also tells us that mx and my are available for other purposes.

With a smart IDE, and careful perusal, you would become aware of all this
anyway. But burying the details about local variables in a dozen assorted
places just obfuscates things and life a bit more difficult.

I was going to say that making in-place declarations makes things easier to
write, harder to read, but then imagine having to clutter your code with
three lots 'PyNumberMethods' instead of one!

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#22362

On 06/18/2012 07:34 AM, BartC wrote:
> 
> 
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:jrkm86$43k$1@dont-email.me...
>> On 06/17/2012 06:47 AM, BartC wrote:
>>> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
>>> news:slrnjtr16f.rk7.grahn+nntp@frailea.sa.invalid...
...
>>> 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?

As others have pointed out, this indicates that your function is
probably too long to be well-understood.

>> 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.
> 
> That means looking at every line of code before that point,

I suppose so, but it's the backward-search feature of my text editor
that does the looking, it's not at all tedious for me.

> ... for a variable
> name that be similar to many others.

Similarity doesn't matter to the backwards-search feature. Just cut and
paste the variable name into the search pattern, and you'll guarantee
it's the one you're looking for. If you can't find it, there's been a
misspelling. Choose the "whole words only" option (if available in your
editor), and you won't have to worry about false positives from other
identifiers whose names contain that variable's name.

> ... Declarations at the start of a function
> are easier for low-tech editors (even with one that can't switch quickly 
> between two locations, probably you can run two instances of it).

My favorite editor (vi) is fairly low tech, and available just about
everywhere I need it; you may be less lucky. I don't think anyone should
settle for using a editor on a modern (in this case, modern means post
1980's) system that's not capable of backwards search.

Note: I would not recommend vi for new users; the learning curve is
quite steep, GUI editors are much easier to use, particularly if built
into an IDE. However, I've already learned it, and once you've learned
them, the power of vi's commands can be quite addictive. I've never seen
a GUI editor (other than gvim, which doesn't really count) where I could
do all (or even most) of the things I can do with vi commands.

>>> ... 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.
> 
> Look at this example from the middle of a function (from Python sources):
> 
>       mz = z->ob_type->tp_as_number;
> 
> Applying a local declaration, and let's say you're lucky and this the first
> use of mz you see, it might look like:
> 
>      PyNumberMethods mz = z->ob_type->tp_as_number;
> 
> That's great; we know what mz is. Except that's not the full picture. The mz
> variable is actually declared like this at the top of the function:
> 
>         PyNumberMethods *mv, *mw, *mz;
> 
> Now we know there are three related variables, and there aren't any called
> mx or my. Which can give an extra dimension to our knowledge (there are
> parameters v, w, z, and mv, mw, and mz presumably correspond to these). It
> also tells us that mx and my are available for other purposes.
> 
> With a smart IDE, and careful perusal, you would become aware of all this
> anyway. But burying the details about local variables in a dozen assorted
> places just obfuscates things and life a bit more difficult.

My experience is the opposite. Putting declarations closer to the point
of use highlights them, it doesn't bury them in a huge pile of other
variables. Knowing that a given variable will be used only in one
particular inner scope makes it easier to understand it's meaning, not
harder.

Of course, the best way to document the meaning of a variable is with a
comment on the line where it's declared, or if there's not enough room
for that, on the previous or following line (it doesn't matter which,
but it does matter that the choice of 'previous' or 'following' be
consistent throughout a given body of code).

> I was going to say that making in-place declarations makes things easier to
> write, harder to read, but then imagine having to clutter your code with
> three lots 'PyNumberMethods' instead of one!

I often will do that even if they were all declared at the top of the
same block; only if they were all closely related variables of the same
type with short names would I merge their declarations like that. And if
those conditions are met, I'd carefully consider whether they should be
elements of a single array, rather than separate variables.

Using multiple declarations also often allows enough room for a short
descriptive comment on the declaration line.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#22363

On Jun 18, 1:18 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> I've never seen a GUI editor (other than gvim, which doesn't really count)
> where I could do all (or even most) of the things I can do with vi commands.

*cough*

M-x all-hail-emacs

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web