Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: RMS's reply to Doug Gwyn's reply to RMS's comments on ANSI C
Message-ID: <5556@brl-smoke.ARPA>
Date: Fri, 23-Jan-87 17:28:18 EST
Article-I.D.: brl-smok.5556
Posted: Fri Jan 23 17:28:18 1987
Date-Received: Mon, 26-Jan-87 01:39:58 EST
References: <2788@mit-hermes.AI.MIT.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

(Reminder: this is not an official X3J11 response.)

Thanks to RMS again for additional discussion of these matters.
I believe that he has indeed uncovered several potential areas
of ambiguity or confusion that the committee should address.  I
wish he had been able to participate in formulating the draft,
but am happy that he has taken the trouble to scrutinize it so
carefully.  Hopefully the next publication will be "good enough"
for use as the initial official C standard.  (People wanting
extensions could prepare implementations of them and develop
supporting evidence for their desirability for the next standard,
which would probably be at least 5 years after the initial one.)

I really don't know what we will end up doing about the linker
external-symbol arithmetic issue.  Dave Prosser remarked to me
that even
	extern int	foo;
	static char	*bar = (char *)&foo;
are impossible for some linkers.  It may well turn out that C
a la X3J11 will pretty much force initializer via "constructor
thunks" (performed once, at run-time start-off or upon first
access to the object).  I sure hope we can avoid demanding that.
However, I don't know how to formulate appropriate (universal)
restrictions on initializers to prevent this (other than outlawing
initializing with addresses of externs, which we really do need
to have).  Suggestions for this are solicited.