Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!ames!ucbcad!ucbvax!decvax!minow
From: minow@decvax.UUCP (Martin Minow)
Newsgroups: comp.lang.c
Subject: Re: ANSI C -- miscellaneous suggestions
Message-ID: <115@decvax.UUCP>
Date: Tue, 16-Dec-86 19:15:50 EST
Article-I.D.: decvax.115
Posted: Tue Dec 16 19:15:50 1986
Date-Received: Wed, 17-Dec-86 19:34:44 EST
References: <112@decvax.UUCP> <5458@brl-smoke.ARPA>
Reply-To: minow@decvax.UUCP (Martin Minow)
Organization: Ultrix Eng. Group - Merrimack, NH
Lines: 42

Sorry about the length of this, but my original comments apparently
require clarification.  I'm greatful to Doug Gwyn (@ brl-smoke.arpa)
for his comments.

1. I recommend that the total list of words be standardized (excepting
   those defined with an initial underscore.  This (hopefully) prevents
   proliferation of new quasi-reserved words. I.e. I want a guarantee
   that Ansi will never add a foo() function to .

2. Horizontal tab has an independent existance in the pre-processor
   (page 74, lines 26-29).  It shouldn't (if I understand translation
   phases).

3. (Specifying internal representations linked to Latin 1) -- I understand
   that is infeasable to *require* ANSI (or Latin 1), but I would recommend
   defining Latin 1 as a reference, and stating that, for implementations
   supporting Latin 1, the internal representations of the specified
   characters *shall* be that given by Latin 1.  (You are also free to
   give representations for EBCDIC, if you can find a standard.)

4. Doug asks where VT and FF are declared "equivalent to newlines."
   That's my reading of section 2.2.2 (page 11) defining character
   display semantics.  If this is not the case, perhaps a clarification
   is in order.

5. I note that a sequence such as
	#define foo	0
	#if 0 && 10 / foo
	int this;
	#else
	int that;
   should not result in an error.  Doug seems to agree.  Unfortunately,
   this bugchecks at least one C compiler.  (And I had to work hard
   in Decus cpp to prevent it.)  The problem is that some preprocessors
   do not properly "short-circuit" evaluate && || and ?:.  Also, the
   standard should clarify just what happens if you do write
	#if 10 / 0
   I doubt that bugchecking is correct behavior.  I don't see anything
   in section 3.8.1 (pp. 75ff) discussing this.

Martin Minow
decvax!minow