Re: Why do people say 'extern' is error prone ?

[user923005]

On Apr 11, 6:06*pm, Eric Sosman <[e-mail]:

Bartc wrote:

[...]
But take this one example of a global variable (the code was not C):

byte winnt * */* set to 1 when this is WinNT, 0 otherwise */

What was I supposed to do with that? A few functions out of thousands need
to know that value.

* * *I have no patience with zealots who argue that all global
variables are ipso facto evil. *When someone does so, I delight
in offering

* * * * #include <stdio.h>
* * * * int main(void) {
* * * * * * puts("Hello, world!");
* * * * * * return 0;
* * * * }

... and inviting him to eliminate the global variable, that is,
the global variable whose name isn't even mentioned!

prog output.txt
But I guess when you look at the data eventually, the global variable
will rear its ugly head.

* * *And yet, I feel there is reason to avoid global variables.
They grow like kudzu, they induce unexpected and unwanted
couplings between modules that could have been independent, they
make debugging harder ("I can see that foo() crashes because the
value of global variable bar is invalid, but how in God's green
earth did bar get clobbered?") *And there's always the chance --
as in my lengthy tale of woe upthread -- that your code will be
recycled into a situation where the Singleton is non-singular
and encounters a singularity ...

* * *I use 'em, but only when there are no witnesses.

After chasing down problems due to globals (it used to be worse, with
Fortran common blocks which were often treated like public unions)
it's easy to get sick of 'em.

They are not all evil. Only most of them.
The ones I hate are the totally unnecessary ones, spawned from lazy
thinking.

[pereges]

So far in my code, I haven't used a single static variable or a const
variable(I prefer to #defining constants and have them at one place in
common.h file) either. I just never felt the need to do it so far. I
don't know if the C gurus consider this as a good practice.

[Ian Collins]

pereges wrote:

So far in my code, I haven't used a single static variable or a const
variable(I prefer to #defining constants and have them at one place in
common.h file) either. I just never felt the need to do it so far. I
don't know if the C gurus consider this as a good practice.

#define constants are the scourge of the maintenance programmer. They
are often impossible to read in a debugger.

--
Ian Collins.

[Richard Heathfield]

pereges said:

So far in my code, I haven't used a single static variable or a const
variable(I prefer to #defining constants and have them at one place in
common.h file) either.

#define has gained a strangely poor reputation amongst some C programmers,
and one that I don't really understand. The principal objection seems to
be that, in a debugger, they are "impossible to read".

I just tried this in gdb. I don't use gdb a great deal, but I know /how/ to
use it, so I wrote the following program:

#include <stdio.h>

#define X 42

int main(void)
{
printf("%d\n", X);
return 0;
}

and loaded the program into gdb.

+++++++++++++++++++++++++++++++++++++
(gdb) run
Starting program: [...]./foo

Breakpoint 1, main () at foo.c:7
7 printf("%d\n", X);
(gdb) print X
No symbol "X" in current context.
+++++++++++++++++++++++++++++++++++++

Oh deary deary me. But wait!

+++++++++++++++++++++++++++++++++++++
(gdb) list
2
3 #define X 42
4
5 int main(void)
6 {
7 printf("%d\n", X);
8 return 0;
9 }
10
(gdb)
+++++++++++++++++++++++++++++++++++++

Also, of course, we can simply look in the original source code to see the
value. So I really don't see this as being a serious objection.

I just never felt the need to do it so far. I
don't know if the C gurus consider this as a good practice.

It depends who you talk to, I think. (It also depends on whom you consider
to be gurus.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bartc]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:Ab******************************@bt.com...

pereges said:

>So far in my code, I haven't used a single static variable or a const
variable(I prefer to #defining constants and have them at one place in
common.h file) either.

#define has gained a strangely poor reputation amongst some C programmers,
and one that I don't really understand.

I have a problem with #define, finding it a crude way of defining constants
which you don't want as variables.

And, in a language that frowns on globals, #defines have file scope, so I
can't write:

#define size 1200

int main(void)
{
#define size 300
}

Using const int size=1200 works, but it might generate an unncessary
variable. And it's not that difficult to change these 'constants':

#include <stdio.h>

int main(void){
const double pi=3.142;
double *p=(double*)&pi;

*p=2.71828;

printf("Pi = %f\n",pi);
}

Something in-between is needed! Namely, a true immutable constant with a
proper type and normal scope rules.

The principal objection seems to
be that, in a debugger, they are "impossible to read".

>I just tried this in gdb. I don't use gdb a great deal, but I know /how/ to
use it, so I wrote the following program:

I don't use debuggers either. But I think you're saying that, to examine a
'variable' that the debugger doesnt know, one has to go back to the source
code, work backwards to the definition of that variable, and with luck one
may stumble across a simple #define with that value!

Or it could be an expression involving further #defines buried in a myriad
of include files somewhere.

So yes, I can see the problem.

--
Bart

[Antoninus Twink]

On 12 Apr 2008 at 6:24, Richard Heathfield wrote:

I just tried this in gdb. I don't use gdb a great deal, but I know /how/ to
use it, so I wrote the following program:

#include <stdio.h>

#define X 42

int main(void)
{
printf("%d\n", X);
return 0;
}

and loaded the program into gdb.

+++++++++++++++++++++++++++++++++++++
(gdb) run
Starting program: [...]./foo

Breakpoint 1, main () at foo.c:7
7 printf("%d\n", X);
(gdb) print X
No symbol "X" in current context.
+++++++++++++++++++++++++++++++++++++

Oh deary deary me. But wait!

+++++++++++++++++++++++++++++++++++++
(gdb) list
2
3 #define X 42
4
5 int main(void)
6 {
7 printf("%d\n", X);
8 return 0;
9 }
10
(gdb)
+++++++++++++++++++++++++++++++++++++

Also, of course, we can simply look in the original source code to see the
value. So I really don't see this as being a serious objection.

If you're using gcc as a compiler, it supports a -g3 debugging level,
which includes extra information, such as all the macro definitions
present in the program. Some debuggers (notably gdb) then support macro
expansion.

(gdb) r
Starting program: [...]/foo

Breakpoint 1, main () at foo.c:7
7 printf("%d\n", X);
(gdb) p X
$1 = 42
(gdb)

[Flash Gordon]

Richard Heathfield wrote, On 12/04/08 07:24:

pereges said:

>So far in my code, I haven't used a single static variable or a const
variable(I prefer to #defining constants and have them at one place in
common.h file) either.

#define has gained a strangely poor reputation amongst some C programmers,
and one that I don't really understand. The principal objection seems to
be that, in a debugger, they are "impossible to read".

The solution is to upgrade to a better system if that is possible.
Admittedly sometimes it is not.

I just tried this in gdb. I don't use gdb a great deal, but I know /how/ to
use it, so I wrote the following program:

Either you are running versions of gcc and gdb which are too old or you
don't know how to drive them well enough.

#include <stdio.h>

#define X 42

int main(void)
{
printf("%d\n", X);
return 0;
}

and loaded the program into gdb.

+++++++++++++++++++++++++++++++++++++
(gdb) run
Starting program: [...]./foo

Breakpoint 1, main () at foo.c:7
7 printf("%d\n", X);
(gdb) print X
No symbol "X" in current context.
+++++++++++++++++++++++++++++++++++++

Oh deary deary me. But wait!

markg@brenda:~$ gcc -g3 -ansi -pedantic -Wall -Wextra t.c
markg@brenda:~$ gdb ./a.out
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) b main
Breakpoint 1 at 0x8048385: file t.c, line 7.
(gdb) r
Starting program: /home/markg/a.out

Breakpoint 1, main () at t.c:7
7 printf("%d\n", X);
(gdb) p X
$1 = 42
(gdb)

Works for me.

<snip>

>I just never felt the need to do it so far. I
don't know if the C gurus consider this as a good practice.

It depends who you talk to, I think. (It also depends on whom you consider
to be gurus.)

I would use #define (or enum for an integer if I want scope) rather than
a const variable. However, opinions do differ.
--
Flash Gordon

[Richard Heathfield]

Flash Gordon said:

<snip>

Either you are running versions of gcc and gdb which are too old or you
don't know how to drive them well enough.

It's the former - my gdb is "too" old (well, it's old, anyway).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Flash Gordon]

Richard Heathfield wrote, On 12/04/08 13:13:

Flash Gordon said:

<snip>

>Either you are running versions of gcc and gdb which are too old or you
don't know how to drive them well enough.

It's the former - my gdb is "too" old (well, it's old, anyway).

So now you have a reason to upgrade your tool chain :-)
--
Flash Gordon

[Richard Heathfield]

Flash Gordon said:

Richard Heathfield wrote, On 12/04/08 13:13:

>Flash Gordon said:

<snip>

>>Either you are running versions of gcc and gdb which are too old or you
don't know how to drive them well enough.

It's the former - my gdb is "too" old (well, it's old, anyway).

So now you have a reason to upgrade your tool chain :-)

I do? Why would *I* want to look up #define values in gdb? That's what
editors are for, innit? (Or grep.)

I have never really understood this craze for plugging the latest bugs into
a production environment, where there is no good business case for doing
so. And as far as I'm concerned, my principal development machine *is* a
production environment, so I don't change *any* of its tools (and least of
all its OS) without a cracking good reason and a fair amount of testing.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Flash Gordon]

Richard Heathfield wrote, On 12/04/08 17:10:

Flash Gordon said:

>Richard Heathfield wrote, On 12/04/08 13:13:

>>Flash Gordon said:

<snip>

Either you are running versions of gcc and gdb which are too old or you
don't know how to drive them well enough.
It's the former - my gdb is "too" old (well, it's old, anyway).

So now you have a reason to upgrade your tool chain :-)

I do?

Yes. Whether it is a sufficient reason is for you to decide, but it is a
reason.

Why would *I* want to look up #define values in gdb? That's what
editors are for, innit? (Or grep.)

If you are in gdb why throw up another tool? It also means that you can
evaluate a sub-expression easily using copy/paste even if it contains
macros.

I have never really understood this craze for plugging the latest bugs into
a production environment, where there is no good business case for doing
so. And as far as I'm concerned, my principal development machine *is* a
production environment, so I don't change *any* of its tools (and least of
all its OS) without a cracking good reason and a fair amount of testing.

You don't need to go to the latest versions to get this feature.

In any case, I did not say it was sufficient reason on it's own, but it
is a reason.
--
Flash Gordon

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

Flash Gordon said:

>Richard Heathfield wrote, On 12/04/08 13:13:

>>Flash Gordon said:

<snip>

Either you are running versions of gcc and gdb which are too old or you
don't know how to drive them well enough.

It's the former - my gdb is "too" old (well, it's old, anyway).

So now you have a reason to upgrade your tool chain :-)

I do? Why would *I* want to look up #define values in gdb? That's what
editors are for, innit? (Or grep.)

Once has to laugh. You are clearly totally ignorant on how to use a good
debugger. I hate to think of the time and money you waste doing it "your
way" using outdated tools and thinking.

>
I have never really understood this craze for plugging the latest bugs into
a production environment, where there is no good business case for
doing

Latest bugs?

so. And as far as I'm concerned, my principal development machine *is* a
production environment, so I don't change *any* of its tools (and least of
all its OS) without a cracking good reason and a fair amount of
testing.

Yes and travelling at 25 Mph on a train will cause your head to blow
off.

Sheesh.

[Richard Heathfield]

Flash Gordon said:

Richard Heathfield wrote, On 12/04/08 17:10:

<snip>

>Why would *I* want to look up #define values in gdb? That's what
editors are for, innit? (Or grep.)

If you are in gdb why throw up another tool?

That's a huge "if"! :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999