Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!shlump.nac.dec.com!tkou02.enet.dec.com!jit345!diamond
From: diamond@jit345.swstokyo.dec.com (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: translation limits
Message-ID: <1991Apr10.004005.22116@tkou02.enet.dec.com>
Date: 10 Apr 91 00:40:05 GMT
References: <14287@darkstar.ucsc.edu>
Sender: usenet@tkou02.enet.dec.com (USENET News System)
Reply-To: diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 28

In article <14287@darkstar.ucsc.edu> daniel@terra.ucsc.edu (Daniel Edelson) writes:

>The section on translation limits is extremely weak.  Perhaps finding
>stronger language that would still be correct was too difficult.

I think so.  If you want to propose better language for the C++ standard
or for the next C standard, you have a chance.  You could even try the
present ISO C deliberations, but your chance is infinitesimal.

>	struct S {
>		int a1;
>		int a2;
>		...
>		int a127;
>	};
>	int main(void) { return 0; }
>	Error: too many structure members. (This is not the one program
>	that may contain 127 members in one particular structure.)
>From reading this section, it does not appear that a strictly conforming
>implementation needs to be able to translate and execute any program
>whatsoever, except for ``the one.''

That is true.  I don't think we should accuse the ANSI committe of INTENDING
to encourage low-quality implementations (not in this case, anyway).
However, they did have to allow it, for the reason that you mentioned above.
--
Norman Diamond       diamond@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.