I will point out that there is a section called "Translation limits" that discusses how compilers can't really be excepted to compile every legal program, because they run in a machine with a finite amount of memory.

> Both the translation and execution environments constrain the implementation of language translators and libraries. The following summarizes the language-related environmental limits on a conforming implementation; the library-related limits are discussed in clause 7.

> 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:

> 4095 characters in a logical source line

Of course, it notes:

> Implementations should avoid imposing fixed translation limits whenever possible.

Note that these aren't strict limits, and don't really have an effect on the legality of your program, I feel it's more of a discussion of the limits imposed by reality, and what compilers must handle at a bare minimum.

And honestly, I would hope most modern compilers would do better than the noted limits and I'd also hope for a decent error message, not "gcc: internal compiler error: Segmentation fault (program cc1)" (which is what the program generates).

Last,

> This is legal C

Is it? You're returning the result of a function that returns void in a function that returns int (and even if main were void, I still don't think that's legal). Were gcc able to handle the abusive number of stars, it would say,

    <stdin>: In function ‘main’:
    <stdin>:1:23: error: void value not ignored as it ought to be

(which is what it says if you remove some of the stars.) Granted, this can be corrected, and your example will still cause the same output. (Which doesn't seem nearly as interesting as the linked C++ code. I'd like to know why that causes a segfault. With yours, I'd like to know why you were doing that.)

You are right in that the return is wrong and accidentally stayed in during example reduction down to a smaller version. Without it, the result is still the same.

The reason I was testing this was a discussion on IRC about functions decaying to pointer to functions, such that they are endlessly dereferenceable. The snippet above crashes GCC -- hard.

So, while the implementation is free not to handle 10^7 dereferencing operations, I'm not sure a hard crash is the right answer.

Here's a version without the return and using a lambda to shorten it further:

    python -S -c 'print("int main(){(" + "*"*10**7 + "+[]{})();}")' | g++ -std=c++11 -xc++ -

Depending on available memory, attempting to compile an expression with ridiculously large numbers of nested parentheses (e.g. "return (((...(42)...)));" will also do the trick.

I don't expect a compiler to be able to compile programs that exceed its internal limits, but a better error message would be much appreciated, instead of a hard crash. For comparison, with MSVC the parent's code produces

    fatal error C1026: parser stack overflow, program too complex

and the nested parentheses results in

    fatal error C1013: compiler limit : too many open parentheses

This segfaults too, so it's "just" a problem of too many dereferences.

  python -c 'print ("int main(){" + "*" * (10**6) + "}")' | gcc -x c -

Sure it's legal, but the bug you are demonstrating is uninteresting. It may not even technically be a violation of the C standard

The error message is unhelpful and requests the user to submit a bug report. I would argue this is not good behavior no matter how absurd the input is.

What were you doing that lead to you finding this?

printing lots of stars?

The C program doesn't print stars. It appears to just call f. It just dereferences f quite a bit before eventually calling it. (He's printing stars in Python simply because it's a more concise way to represent a million stars.)

Stack overflow?

Yes, you're able to confirm this by setting:

    ulimit -s unlimited