cc bug in definition of global variables?

Yogesh K Gupta gupta at asgb.UUCP
Tue Nov 19 04:04:03 AEST 1985


The following seems to be a bug in the SYSV.2 C-compiler (loader really):
You can DEFINE the same global variable in two files and the loader does
not even issue a warning about it.  In fact, you can DEFINE the same global
variable in two files as two DIFFERENT data types and the loader does not
issue a warning as long as the size of the two globals is the same.  Also,
it really treats them as one global variable.  Thus, the effect is the same
as declaring the global as the union of the two declarations (as an example,
try the program at the end of this message).

This behavior of the compiler is contrary to what is mentioned in K&R.
To quote, (pp 77, italicized words from the text are shown in upper case):
    "    There must be only one DEFINITION of an external variable
	       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    among all the files that make up the source program;  others
    may contain 'extern' declarations to access it."
Also, on page 206 (Appendix A):
    "Thus in a multi-file program, an external data definition without
    the 'extern' specifier must appear in exactly one of the files."
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

System: Vax-780.
Unix:   USG V.2
/*  Begin tst1.c */
struct {
	short x;
	short y;
	} a;

f1()
{
	printf("f1: &a: %d, a.x: %d, a.y: %d\n",&a,a.x,a.y);
}

main()
{
	f2();
	f1();
	printf("main: &a: %d, a.x: %d, a.y: %d\n",&a,a.x,a.y);
}
/*  End   tst1.c */

/*  Begin tst2.c */
int  a;

f2()
{
	a = 1 + (1 << 16);
	printf("f2: a: %d &a: %d\n",a, &a);
}
/*  End   tst2.c */
---- Begin output of the compilation of the above program ----
f2: a: 65537 &a: 73136
f1: &a: 73136, a.x: 1, a.y: 1
main: &a: 73136, a.x: 1, a.y: 1
---- End output ----
-- 
Yogesh Gupta                           Advanced Systems Group,
{sdcrdcf, sdcsvax}!bmcg!asgb!gupta     Burroughs Corp., Boulder, CO.
--------------------------------------------------------------------
	All opinions contained in this message are my own and do not
	reflect those of my employer or the plant on my desk.



More information about the Comp.lang.c mailing list