daniel@terra.ucsc.edu (Daniel Edelson) (04/10/91)
(I tried to post this before, but our news server was
having problems. I'm not sure if this made it out.
Please disregard if this is a duplicate.)
The section on translation limits is extremely weak.
Perhaps finding stronger language that would still
be correct was too difficult.
The standard says that ``The implementation shall be able to translate
and execute at least one program that contains at least one instance
of each of the following limits:...''
For example, one of the limits is ``127 members in a single structure
or union''. (That limit was chosen at random; any of the 2.2.4.1 limits
would be appropriate for this question.)
So, is it the intention that a strictly conforming implementation could
fail to translate the following code? (note the diagnostic)
/* Begin Example */
struct S {
int a1;
int a2;
...
int a127;
};
int main(void)
{
return 0;
}
/* Begin Error Diagnostic */
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.''
Daniel Edelson
daniel@cis.ucsc.edudiamond@jit345.swstokyo.dec.com (Norman Diamond) (04/10/91)
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.
daniels@ogicse.ogi.edu (Scott David Daniels) (04/10/91)
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.
gwyn@smoke.brl.mil (Doug Gwyn) (04/10/91)
In article <14287@darkstar.ucsc.edu> daniel@terra.ucsc.edu (Daniel Edelson) writes: >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.'' Well, there are a lot of requirements in the standard that a conforming implementation must meet; 2.2.4.1 is merely one of them. It was not feasible to require that all conforming implementations be able to translate and execute ALL strictly conforming programs that do not exceed ANY translation limit, which is what we would have liked to specify. Some otherwise reasonable implementations (for example, on 16-bit processors) were deemed unable to make such a guarantee. It is most unlikely that any implementation would be able to handle "the one" implementor-provided program yet not be able to handle programs such as your example.