Re: global vars and symbol visibility for mips32/elf

[Ruediger Helsch <rh@unifix.de>]

On Tue, 13 Aug 1996, Richard Stallman wrote:

>     Both bugs are since nearly one year fixed in Unifix Linux and Linux-FT
>     (POSIX certified).
> 
> So did you report the bugs, and your fixes, a year ago?  You could
> have enabled the bug to have been fixed in the GNU sources a year ago,
> too.

The nonstandard behaviout in GCC is deliberate.  See the comment in
varasm.c line 1092:

  /* ANSI specifies that a tentative definition which is not merged with
     a non-tentative definition behaves exactly like a definition with an
     initializer equal to zero.  (Section 3.7.2)
     -fno-common gives strict ANSI behavior.  Usually you don't want it.
     This matters only for variables with external linkage.  */

The comment says they know that this does not conform to the C standard,
so why should we report something that seems well-known?

While for the linker, we use a variant of the Linux linker distributed
of H.J.Lu, which is a somehow modified GNU ld. There again somebody did 
the work and put in warning messages for the case that commons were
linked against library functions.  Again, this person obviously knew
what the problem was and deliberately decided to issue a warning instead
of preventing the symbol to match.

In both cases the nonstandard behaviour was nonstandard on purpose.

I am quite surprised to find that everybody thinks that GCC and LD
should be changed.  We modified them for our Linux distributions because
we wanted strict C standard and POSIX conformance.  But the standard
conformant behaviour can also break many programs which rely on COMMONS. 
We had e.g. to adapt the X11 config files to use "cc -ansi -fcommon".

Whether GCC should be changed is a question of policy more than of one of
missing bug reports.

I personally think that either "gcc -ansi" should conform to the C standard
or the option should be renamed (-nearly-ansi), but until shortly this
seemed to be a minority opinion.

Ruediger Helsch <rh@unifix.de>