Dave Hanson <drhanson@[EMAIL PROTECTED]
> writes:
> On Jun 2, 3:09 pm, jacob navia <j...@[EMAIL PROTECTED]
> wrote:
>> ...
>> Is there a limit that the standard for this? In the limits section
>> (5.2.4.1) the standard does NOT mention this kind of limit, at
>> least as far as I can see (PLEASE correct me, I would be happy to be
>> wrong! :-) )
>
> The expression you show is equivalent to its fully parenthesized
> variant. Sec. 5.2.4.1 stipulates "63 nesting levels of parenthesized
> expressions within a full expression." I suspect your example--when
> parenthesized fully--exceeds this limit. Of course, lcc shouldn't
> crash; it should issue a diagnostic, as it does when other limits are
> exceeded, e.g., when there are too many initializers.
I'm not convinced that it's equivalent as far as 5.2.4.1 is concerned.
For example, the expression 42 is equivalent to (((...(((42)))...)))
(64 nesting levels); the latter exceeds the limit, but 42 by itself
does not.
But keep in mind that the limits in 5.2.4.1 are applied *very*
narrowly. The implementation must translate and execute *one* program
that hits every one of the limits. The standard says nothing about
any *other* program that meets or exceeds any of those limits, or
about any measures of size or complexity that aren't enumerated in
5.2.4.1.
The intent of 5.2.4.1, I think, is to discourage implementers from
imposing arbitrary fixed limits. The easiest way to meet the
requirement (to handle *one* complex program) is probably to make all
the compiler's internal data structures dynamic, so the only
limitations are those imposed by compile-time resource constraints.
A conforming compiler cannot reasonably be required to handle
arbitrarily large and complex translation units; nobody expects a
compiler to handle a 3-yottabyte source file. It can only be expected
to do the best it can given the resources available to it. (I think
an explicit statement to that effect in the standard would be a good
thing; if nothing else, it might have forestalled this discussion.)
My advice:
1. Increasing the compiler's available stack space, assuming the
underlying OS provides a way to do this, might alleviate the problem.
Adding more physical RAM to the computer might be one way to do this.
2. If practical, the compiler should abort with an error message
rather than blowing up.
3. The program that generates the offending code should be modified to
generate simpler code, probably by breaking the huge expression into
smaller parts using tem****ary variables.
--
Keith Thompson (The_Other_Keith) kst-u@[EMAIL PROTECTED]
<http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*>
<http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
|
