Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ogicse!daniels
From: daniels@ogicse.ogi.edu (Scott David Daniels)
Newsgroups: comp.std.c
Subject: Re: translation limits
Summary: There is no good way to legislate limits
Message-ID: <19849@ogicse.ogi.edu>
Date: 10 Apr 91 02:04:31 GMT
References: <14287@darkstar.ucsc.edu> <1991Apr10.004005.22116@tkou02.enet.dec.com>
Followup-To: comp.std.c
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR
Lines: 40

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.
(approximately) ... exactly 1 program per limit might be accepted by a 
			conforming translator, and still have it conform.
>it does not appear that a strictly conforming implementation needs to be 
>able to translate and execute any program whatsoever, except for ``the one.''

and In article <1991Apr10.004005.22116@tkou02.enet.dec.com> 
	diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) replies:
>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.


I believe that nobody could come up with a way of stating useful limits
that could be applied accross all target architectures and compiler 
organizations.  Since some implementations would allocate many of these
things from a memory pool, while others would pre-allocate tables, the
current technique simply tries to say "the tables must be at least this
big."  While it was pointed out that very little was guaranteed if there
was no wording to talk about simultaneous limits, it was also clear that
many perfectly good systems would be rejected if the compiler had to handle
all limits simultaneously.

Once you accept that you cannot require the latter, how you specify
anything useful becomes problematic.  The final resolution at the
meeting I was at was, "We cannot create a `reasonable' standard wording,
therefore we will leave that as a `quality of implementation' issue."  
This is not necessarily a cop-out.  Basically, it simply says that 
some junk can conform, and the marketplace will rightfully reject that
as junk even though it is standard-conforming.  It is certainly better
than rejecting good translators that are otherwise conforming simply
because they have been implemented in a style that doesn't fit the 
one that got voted in.

-Scott Daniels
daniels@cse.ogi.edu
No, I don't speak for anyone, and I was a member only very briefly.