Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!aplcen!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: <11716@smoke.BRL.MIL>
Date: 1 Dec 89 00:26:04 GMT
References: <11193@riks.csl.sony.co.jp> <11693@smoke.BRL.MIL> <57@looney.twinsun.com> <11699@smoke.BRL.MIL> <58@looney.twinsun.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 29

In article <58@looney.twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>Doug Gwyn writes:
>>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.
>Does this suggestion mean that the following strictly conforming program with
>two translation units should link correctly, albeit perhaps with warnings?
[omitted to save space]
>Won't most linkers flatly refuse to link this program
>because F is defined twice?

Oops.  Your argument is evidence that multiple external definitions
for the same identifier could not have been the Committee's intent
(since that linker model is the most commonly encountered one).
Therefore the lack of a clear prohibition against multiple definitions
(amongst the entire set of modules constituting a program, not just
confined to a single translation unit) must really have been an
oversight.  In fact, I recall something like that constraint in
earlier drafts, so it probably got lost in the editing that occurred
in this area in response to public review comments on external linkage.

One can still fall back on the ANDIPS and the obvious model of an
object/function as having only one definition implied by phraseology
scattered throughout the Standard to back the "no more than one
definition" interpretation.  However, this one really does need to
receive an official X3J11 interpretation ruling, since it potentially
impacts implementations in a major way.  (Having to support multiple
external definitions would require linker changes in many environments,
and that was definitely not the committee's intention.)