Date: Tue, 20 Sep 94 08:59 PDT
From: jdp AT polstra DOT com (John Polstra)
To: djgpp AT polstra DOT com
Subject: Re: strange linker behavior

Stefan Eckart <S_Eckart AT lis DOT e-technik DOT tu-muenchen DOT de> asks:
> the following program behaves rather strange when compiled with the
> current (1.12m2) release of djgpp:
> 
> #include <stdio.h>
> 
> int delay;
> 
> main()
> {
>   printf("%d\n",delay);
> }
> 
> I would have expected to get a 0 as output, and in fact this was the case
> until v1.11m5. The current version prints a large negative number...
> 
> For some reason the linker merges the .bss symbol 'delay' with a .text symbol
> 'delay' from the runtime library (libsrc/c/dos/delay.s) and printf
> displays the first for opcode bytes of delay()...
> 
> Is this
> 
> a) a programming bug (name clash between an global variable and function name)?
> b) a feature or bug of the binutils 2.4 linker?
> c) a bug in djgpp?

I've seen two wrong answers so far on this list.  The correct answer is c.
It's a bug in djgpp's libc.a, which should not define a global symbol
named "delay".  This is true whether you want djgpp to be ANSI-conforming
or K&R "conforming".

We can take care of the K&R case right away, because K&R "conformance"
is defined by the behavior of the original K&R compiler in its original
environment (PDP-11 Unix).  I worked in that environment for years, and
the compilation system did NOT define any global symbol named "delay".

As for the ANSI C standard, it is very specific about what global
symbols the C library is permitted to define.  "delay" is not one of
them.  In general, the only global symbols that the implementation (the C
library) is allowed to define are:

    a) Symbols beginning with '_' followed by certain other characters, and
    b) Certain specific symbols that have been grandfathered in, e.g.,
       "printf" and "strcpy".

The implementation is absolutely not allowed to pollute any other
portions of the global name space.  The djgpp C library is a bad offender
in this regard.

From one of the other responses (the other one was similar):

> I don't think that there's any provision in the C language for what
> uninitialized variables start out as.  delay could end up as anything!

That is not correct.  Uninitialized external and static variables are
guaranteed, both by ANSI and by K&R, to start out with a value of 0.
This has been the case since day one, and I would wager that the vast
majority of the existing C code in the world relies on it.  And there is
nothing wrong with that, because the language has always guaranteed that
it will work.

PS - Also, most modern linkers would warn about the fact that they were
combining a text symbol with a common symbol.

   John Polstra                                       jdp AT polstra DOT com
   John D. Polstra & Co., Inc.                   Phone (206) 932-6482
   Seattle, Washington USA                         Fax (206) 935-1262
   "Self-knowledge is always bad news."                 -- John Barth