Do non-trivial strictly conforming programs exist?

[Richard Minner]

In some article or other Jeffrey Kegler writes, among other things:

|                           ... Confronted with the choice of trying
| to prevent perverse implementations and of trying to allow ANSI C to
| be ported to the most restrictive of environments, X3J11 went all the
| way over to the second, knowingly and as the result of carefully
| deliberated choice.  Conforming implementations can get very perverse
| indeed as a result.

OK, this makes sense, adding as Doug Gwyn and others have that
one hopes the "marketplace" will weed out any such perverse
implementations.  (Still, I do so pity the poor soles working for
some large bureaucracy who have some truly perverse
implementation specified for them.  Stranger things have
happened.)  What's not clear is why X3J11 couldn't have tightened
up 2.2.4.1 without adversely affecting the standard's chances in
"the most restrictive of environments."  For example could not
2.2.4.1 be worded something like (not exactly, mind you):

    2.2.4.1  Translation limits

	     In so far as the implementation has sufficient
	storage available, it shall be able to translate and
	execute any otherwise conforming program that does not
	exceed any of the following limits: 

	o    (bunches of limits, reworded ever so slightly)

Since this would imply such things as accepting a program with
1024 macros with 31 parameters each, you could to add a limit:

	o    2048 (4096? 1024?) total macro parameters.

Plus any other newly implied totals that may need to be limited,
and maybe distinguish between macros with and without parameters
and so forth.

In other words, it hardly seems fair to expect an implementation
to perform miracles (such as creating memory out of thin air) but
we might reasonably expect it to spread what it has at least
somewhat evenly (more of the "fighting chance" ethic).  I believe
that the above approach would do away with "just one instance of
each limit" perversities without imposing any other restrictions.

Here are just a few guesses as to why 2.2.4.1 is as it is:

1. My concept of "most restrictive of environments" is flawed.
   There are other considerations besides storage capacity
   and the current 2.2.4.1 addresses them as best as possible.

2. One such "restriction" might be that in some environments
   there may be minimal resources (money) available for
   ANSI C compliance.  If such an environment currently
   uses fixed size tables and such, gluing on the current
   2.2.4.1 requirement will be significantly cheaper (if
   pointless) than complying with my suggested 2.4.4.1.
   (I hope this isn't it.)

3. For horridly complex reasons that no one wants to discuss
   any more because it really is late and we want to go home.

If 3, someone just say so and I'll go away.  Otherwise I'd
appreciate any comments.

Thanks to all for a very interesting discussion so far.
And Doug, who's Dave?  Why hasn't he helped yet?




-- 
Richard Minner  || {uunet,sun,well}!island!rtm     (916) 447-7081 ||
                || Island Graphics Corporation     Sacramento, CA ||