4.2 extern a DISASTER (Flame)

Chris Torek chris at umcp-cs.UUCP
Sun Jul 28 07:38:00 AEST 1985


What you have just described is NOT the 4.2 compiler.  (In fact it
sounds alot like the Whitesmiths compiler, but not quite the same.)

Here is your example of something that (you claim) does not work:

>This is where the problem is occuring:
>
>file1.c
>
>int foo;
>
>file2.c
>
>int uses_foo()
>{
>  extern int foo;
>   ...
>}

This code is fine, and works the way you expect (uses_foo() in file2.c
has a variable called "foo" available to it, and it is the same "foo"
as in file1.c).

>If I try to run this, I get various bus errors, etc. (it links OK). 

I would suggest you find the bug in your code, or find out who broke
the compiler and/or linker.

>Furthermore, according to Haberson [sic] & Steele (and I've verified this
>by using the verbose mode of ld), if one defines foo as above, 
>a FORTRAN like COMMON block is allocated for foo, and one could 
>declare foo in file2.c *without* declaring the storage class static
>and *without* declaring foo extern and the linker will *not* make the
>connection between the two.

What "verbose mode of ld"?  Sounds to me like you haven't got a
4.2BSD ld, but some other strange beast.  Also, it's not quite
clear what you are trying to say is happening or is supposed to
happen; but given the following two files, the "foo" in f1() and
the "foo" in f2() are the same variable:

	file1.c:
	int foo;
	f1() { ... }

	file2.c:
	int foo;
	f2() { ... }

In some compilers/linkers, one of the two defintions must be preceded
by "extern" in order to avoid a "multiple definition" linker error
(or more generally, there must be exactly one occurrence of a global
defintion that does not use "extern"); in 4.2BSD Unix (indeed in
every currently available Unix, so far as I know) this is not
necessary.

Returning to "...one could declare foo in file2.c *without* declaring
the storage class static...", if you were to write

	file1.c:
	int foo;
	f1() { ... }

	file2.c:
	f2() { int foo; ... }

you would not be referencing the same piece of storage, since in
this case f2()'s "foo" is an automatic variable, created at function
entry.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at maryland



More information about the Comp.lang.c mailing list