4 ms·

While we're at segfaulting compiler's, here's what I found just a few days ago: python -S -c 'print("void f(){} int main(){return (" + ""10**7 + "f)();}"

While we're at segfaulting compiler's, here's what I found just a few days ago: python -S -c 'print("void f(){} int main(){return (" + "*"*10**7 + "f)();}")' | gcc -xc - (This is legal C -- look it up. Don't argue with me over the practical relevance of this please)

gizmo686 12y ago
What were you doing that lead to you finding this?
- Torn 12y ago
  printing lots of stars?
  - deathanatos 12y ago
    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.)
chrisdevereux 12y ago
Stack overflow?
- danieljh 12y ago
  Yes, you're able to confirm this by setting: ulimit -s unlimited
deathanatos 12y ago
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.)
- danieljh 12y ago
  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++ -
webkike 12y ago
Sure it's legal, but the bug you are demonstrating is uninteresting. It may not even technically be a violation of the C standard
- a3_nm 12y ago
  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.
dbaupp 12y ago
This segfaults too, so it's "just" a problem of too many dereferences. python -c 'print ("int main(){" + "*" * (10**6) + "}")' | gcc -x c -
userbinator 12y ago
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

While we're at segfaulting compiler's, here's what I found just a few days ago: python -S -c 'print("void f(){} int main(){return (" + "*"*10**7 + "f)();}"

gizmo686 12y ago

What were you doing that lead to you finding this?

Torn 12y ago
printing lots of stars?
- deathanatos 12y ago
  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.)

chrisdevereux 12y ago

Stack overflow?

danieljh 12y ago
Yes, you're able to confirm this by setting: ulimit -s unlimited

deathanatos 12y ago

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.)

danieljh 12y ago
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++ -

webkike 12y ago

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

a3_nm 12y ago
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.

dbaupp 12y ago

This segfaults too, so it's "just" a problem of too many dereferences. python -c 'print ("int main(){" + "*" * (10**6) + "}")' | gcc -x c -

userbinator 12y ago

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