Live data from Hacker News

The Following Code Causes Segfault in Clang

llvm.org

11–20 of 40 posts

Re: The Following Code Causes Segfault in Clang

#12
post #4

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)

Stack overflow?

Re: The Following Code Causes Segfault in Clang

#13
post #4

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)

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,

    : In function ‘main’:
    :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.)

Re: The Following Code Causes Segfault in Clang

#14
post #4

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)

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

Re: The Following Code Causes Segfault in Clang

#15
post #4

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)

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 im…

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

Re: The Following Code Causes Segfault in Clang

#16
post #3

Is there some legitimate reason to want to have A's destructor called twice on a single instance?

Yeah, maybe this is just a standard-conforming implementation of undefined behavior.

It's nothing to do with standard-conforming or not. A correct implementation shall never crash.

Re: The Following Code Causes Segfault in Clang

#18
Something I found last week that crashes with clang-503.0.40:

    template class foo
    {
    public:

        ~ foo()
        {
        }

        foo &operator = (const foo &rhs)
        {
            foo::~foo();
            new (this) foo (rhs);

            return *this;
        }
    };

    int main(int argc, char * argv[])
    {
        foo a, b;
        b = a;
    }

Re: The Following Code Causes Segfault in Clang

#19
post #4

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)

Stack overflow?

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

    ulimit -s unlimited

Re: The Following Code Causes Segfault in Clang

#20

Something tells me C++ isn't the best thing to implement a compiler with.

This looks to be an assertion failure, i.e. code that was thought to be unreachable is not. So there's no evidence that any of the negatives of C++ (memory safety, etc.) are in play here.
Post reply on HN