4

(This question was prompted by an answer to this previous question)

The C11 standard makes use of the following formulation when discussing the complexity of programs which a compliant compiler should be able to support:

5.2.4.1 Translation limits

The implementation shall be able to translate and execute at least one program that contains at least one instance of every one of the following limits:

...

  • 127 arguments in one function call

...

This "at least one" phrasing seems curious to me, as it appears like a standards compliant program could put arbitrary restrictions on most usages and still be compliant. For example, by having a 63 argument limit on variadic functions, but a 127 argument limit for functions with explicit parameters. Or requiring that only functions with names starting "BIGARG_" can be called with more than 99 parameters. Or some other such restriction.

Even with potentially arbitrary restrictions, there could be some odd condition where the 127 argument limit would be supported, so at least one program that contains at least one instance of that limit could be translated and executed. It's just that not all - or even most - programs that come close to that limit would be supported.

Is there a rationale for this particular phrasing? Why not explicitly require support of every program (else-wise compliant) which obeys those limits? Or is there some other mechanism to require uniform support of, for example, 127 arguments in function calls?

Community
  • 1
  • 1
R.M.
  • 3,461
  • 1
  • 21
  • 41
  • Consider that C is an almost universal language and those restrictions are related more to hardware limitations of some platforms than software limitations. – Frankie_C Feb 27 '16 at 19:29
  • Did you overlook the word "every" in the quote? The "at least one program" contains all of the things in the bullet points. , there's not separate programs for each point – M.M Feb 27 '16 at 23:16
  • @M.M The "every" refers to the bullet points. I'm asking about multiple instances of a single particular bullet point. – R.M. Mar 01 '16 at 16:06

2 Answers2

3

Yes, an implementation could place arbitrary restrictions on the programs it can handle while still conforming to the letter of the standard. But the intent of 5.2.4.1 is that the easiest way to meet its specific requirements is to support reasonable limits for all programs.

You could create a single program that hits every one of the translation limits defined in 5.2.4.1 (and that, for example, produces no output), then write a "compiler" that recognizes that single program and produces an executable that does the equivalent of int main(void){}, while rejecting every other program with a diagnostic message saying that it exceeds the implementation's translation limits.

Such a compiler would, of course, be completely useless, which is why (as far as I know) nobody has bothered to create such a thing. (I've thought about doing it myself, just for the heck of it.)

In practice, compiler writers want to produce useful compilers that will correctly compile real C code.

The requirements of 5.2.4.1 are designed so that the easiest way to satisfy them (if you're writing a useful C compiler) is to impose as few actual limits as possible.

For example, a conforming compiler must support 127 nesting levels of blocks for that mythical "one program". The easiest way to meet that requirement is to support an arbitrary depth of nested blocks by having the compiler use dynamic data structures. In practice, the depth is limited, not by a hardwired limit in the compiler source, but by the amount of memory available at compile time. (Or a compiler could use some fixed-size internal data structure that permits exactly 127 levels, but it's probably easier to permit dynamic sizes.)

You might think it would be better for the standard to impose more "reasonable" requirements, so that a conforming compiler must accept all programs that do not exceed certain specified limits. The problem is that such "reasonable" limits are extremely difficult to specify precisely. There are always going to be some programs that exceed the capacity of a compiler -- and the size or complexity of such programs depends on the internal data structures and algorithms used by the compiler, and by the capacity of the particular system the compiler is running on. There was no way the standard could cover such details, or anticipate what limits might be "reasonable" for future systems.

Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
  • Could the same idea, that compilers are reasonable, give us some hard limits of what undefined behavior can _actually_ do? – John Dvorak Feb 27 '16 at 19:47
  • 1
    @JanDvorak: I don't think so. Compilers can and do generate code *assuming* that the code does not have undefined behavior. If that assumption is violated, the results can be arbitrarily serious, limited only by the physical capabilities of the underlying hardware. For example, much malware exploits buffer overruns (accessing memory outside an object); the consequences can adversely affect other internet-connected computers. – Keith Thompson Feb 27 '16 at 19:54
3

The standard cannot require an implementation to accept all such compliant programs. Consider several limits, say, 127 nesting levels of blocks and 511 identifiers with block scope. Now imagine a program that has 127 levels of nesting blocks and 511 identifiers in each of those levels. Throw in 63 significant characters in each identifier, and you've got a program of a formidable size. An implementation that runs on a 16-bit microcomputer like, say, PDP-7 :) probably wouldn't be able to cope with it.

n. m. could be an AI
  • 112,515
  • 14
  • 128
  • 243
  • Then why have any such requirements in the first place? If you are only assured of having 511 identifiers under some specific arbitrary conditions, how is that any better than not having any guarantees at all? – R.M. Mar 01 '16 at 16:12
  • Perhaps it's because the compiler game is not about screwing the user in the worst possible way while still being conforming. But yes, I'm not exactly sure what's the point of this requirement either. It should be a non-normati e guideline IMHO. – n. m. could be an AI Mar 01 '16 at 17:32