public inbox for gas2@sourceware.org
 help / color / mirror / Atom feed
From: Jim Wilson <wilson@chestnut.cygnus.com>
To: Ruediger Helsch <rh@unifix.de>
Cc: Ian Lance Taylor <ian@cygnus.com>,
	rms@gnu.ai.mit.edu, drepper@cygnus.com, dm@sgi.com,
	gcc2@cygnus.com, gas2@cygnus.com
Subject: Re: global vars and symbol visibility for mips32/elf
Date: Tue, 13 Aug 1996 13:36:00 -0000	[thread overview]
Message-ID: <199608131920.MAA26625@cygnus.com> (raw)
In-Reply-To: <Pine.LNX.3.91.960813173031.26776I-100000@anna.unifix.de>

	Wrong.  A standard conforming compiler will conclaim about a multiply
	defined symbol.

This is not correct.  You have missed a subtle point here.

A program that has multiple external definitions is not a strictly conforming
program.  If you want your programs to be strictly conforming, then you can not
rely on common.

A conforming compiler must accept any strictly conforming program.  However, a
conforming compiler can have extensions that allow it to accept non-strictly
conforming programs providing that such extensions do not change the behaviour
of any strictly conforming program.

The standard says that a program with multiple external definitions results
in undefined behaviour.  A standard conforming compiler can do anything when
an input program triggers undefined behaviour.  Normally, we give a warning
to encourage portable programming.  In this particular case, gcc chooses to
have an extensions that allows such programs to work.

This extension is even sanctioned by the standard (in a sense), as it is
documented in the section on common extensions.

A very similar case is identifier names.  Consider this program:
	int abcdef1;
	int abcdef2;
This is not a strictly conforming program.  The standard says that only
the first 6 characters are guaranteed to be significant, and it is
implementation defined whether any characters after the first 6 are used.
Gcc however accepts this program without complaint, and it would be very
unwise to change this.  In this case, we do not want to enforce the strict
limits of the standard, because that is far too inconvenient for programmers.

It is debatable whether multiple external definitions deserves the same
treatment.  It is not a bug in gcc that it accepts them though.

Jim


  reply	other threads:[~1996-08-13 13:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-08-09  2:46 David S. Miller
1996-08-09  5:24 ` David S. Miller
1996-08-09  9:01   ` Ian Lance Taylor
1996-08-09  8:30 ` Ian Lance Taylor
1996-08-09 13:13   ` Ulrich Drepper
1996-08-09 15:30     ` Ian Lance Taylor
1996-08-10 17:37       ` Richard Stallman
1996-08-10 19:41         ` Ian Lance Taylor
1996-08-10 23:26           ` Jim Wilson
1996-08-11  1:44           ` Richard Stallman
1996-08-13 10:58           ` Ruediger Helsch
1996-08-13 13:36             ` Jim Wilson [this message]
1996-08-13 16:06               ` Ruediger Helsch
1996-08-13 19:04                 ` Jim Wilson
1996-08-13 21:02                   ` Richard Stallman
1996-08-14  3:06                     ` Ruediger Helsch
1996-08-14 23:44                       ` Richard Stallman
1996-08-14  0:18                 ` Nick Ing-Simmons
1996-08-14  3:06                   ` Ruediger Helsch
1996-08-15 11:24                   ` H.J. Lu
1996-08-13  9:06 ` Ruediger Helsch
1996-08-13 10:58   ` Richard Stallman
1996-08-13 13:36     ` Ruediger Helsch
1996-08-13 13:36       ` Richard Stallman
1996-08-13 14:40       ` H.J. Lu
1996-08-13 16:06       ` Ulrich Drepper
1996-08-13 16:06         ` Joe Buck
1996-08-13 17:02         ` Rohan LENARD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199608131920.MAA26625@cygnus.com \
    --to=wilson@chestnut.cygnus.com \
    --cc=dm@sgi.com \
    --cc=drepper@cygnus.com \
    --cc=gas2@cygnus.com \
    --cc=gcc2@cygnus.com \
    --cc=ian@cygnus.com \
    --cc=rh@unifix.de \
    --cc=rms@gnu.ai.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).