Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: multiple definitions of identifiers with external linkage
Message-ID: <11699@smoke.BRL.MIL>
Date: 28 Nov 89 20:10:02 GMT
References: <11193@riks.csl.sony.co.jp> <11693@smoke.BRL.MIL> <57@looney.twinsun.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 32

In article <57@looney.twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>The real problem is a bug in the wording in 3.7 (External definitions).
>This bug applies to both objects and functions, so it also permits multiple
>definitions of unused functions with external linkage.  HP's Walter Murray
>pointed this out in a news posting, as did Twin Sun's Mike Coleman when he
>originally brought this problem to my attention.  Thus, the following
>program is strictly conforming even though it's ``obviously'' wrong:
>	int F(){return 0;}
>	int F(){return 1;}
>	int V = 0;
>	int V = 1;
>	int main(){return 0;}
>Even assuming that the above quote from 2.1.2 prohibited the two Vs,
>it wouldn't address the problem of the two Fs.

As indicated by the footnote, this wording ("if ... is used in an
expression") was designed to permit ZERO definitions for unused objects
and functions, to support existing practice.  (Some compilers cannot
reasonably generate references to unused, albeit declared, external names.)
While agreeing that the wording in 3.7 would have been better if it had
explicitly prohibited MULTIPLE definitions for unused objects or functions,
I still don't think that there is a large practical problem in correctly
implementing this, because throughout the Standard the notion that a
particular named external function has A definition, not a class of
definitions, is quite obvious.  And when a definition has no use it
really doesn't matter whether or not it is multiple, apart from the
question of how to implement this so that "strictly conforming" code that
abuses this loophole will be accepted.  My suggestion is to generate a
warning (not an official diagnostic) for the second definition within a
translation unit, and generate code for only the first definition.
Inter-translation unit multiple definitions are handled the usual way
(typically by the linker).  That technique should be standard conforming.