QFile::close() leads to SIGILL

[JonB]

@SGaist said in QFile::close() leads to SIGILL:

Strictly speaking it's not undefined behaviour. You will print a random value from an uninitialized int variable.

"No", that's what I was saying, but I think you are "incorrect" here! [Hesitant, you usually shoot me down, fools rush in where... :) ]

The best "official" I can find is https://en.cppreference.com/w/cpp/language/ub. Note the difference between

• unspecified behavior: Each unspecified behavior results in one of a set of valid results.

• undefined behavior: there are no restrictions on the behavior of the program

Then note that (confusingly) it uses the abbreviation UB, which if you read carefully is the undefined rather than the unspecified behaviour. I take this from:

Because correct C++ programs are free of undefined behavior, compilers may produce unexpected results when a program that actually has UB

Hence I understand UB == undefined behaviour. Then proceed to the examples.

    std::size_t a;
    if(x) // either x nonzero or UB
        a = 42;

and

bool p; // uninitialized local variable
if(p) // UB access to uninitialized scalar
    std::puts("p is true");
if(!p) // UB access to uninitialized scalar
    std::puts("p is false");

So if UB == undefined behaviour, they are saying these could "crash". Otherwise you have to show that this UB == unspecified behaviour, which I do not see from the text I quoted. That's my reading, don't you think?

[Christian Ehrlicher]

@JonB said in QFile::close() leads to SIGILL:

they are saying these could "crash".

Correct, since x is not defined the compiler may decided to e.g. throw an exception, quit the program or simply use the value which it finds at the specified address.

[JonB]

@Christian-Ehrlicher
Going all the way back to the @Sedi's original

Qt 5.15.0 for Android, working on a Win10 machine

Purely OOI, what compiler does this mean he will be using? It would be interesting to see from one of those "web public compilers" what code it generates that leads to SIGILL....

[Christian Ehrlicher]

I would guess it's clang: https://godbolt.org/z/qGaKeM
/edit: msvc doesn't even compile it

[JonB]

@Christian-Ehrlicher
Thanks Christian. That "Compiler Explorer" site doesn't seem to be one which has an option of running code? Do you know of one which offers the necessary compiler but also runs code? I'd like to see that SIGILL actually happen, as per the OP :)

Or, failing that, can you explain what instruction in the generated code would actually cause it? Remember, the OP doesn't actually use the returned result from the function (which doesn't return a result), his case is just supposed to be:

bool func()
{
}

void main()
{
  func();
}

[Christian Ehrlicher]

@JonB said in QFile::close() leads to SIGILL:

Or, failing that, can you explain what instruction in the generated code would actually cause it?

Simply take a look at the godbolt assembler output and read the tooltip :)

doSomething():                       # @doSomething()
        push    rbp
        mov     rbp, rsp
        ud2

[SGaist]

@JonB said in QFile::close() leads to SIGILL:

"No", that's what I was saying, but I think you are "incorrect" here! [Hesitant, you usually shoot me down, fools rush in where... :) ]

I see your point now. Semantic is quite complex and your analysis is correct :-)
Undefined VS Unspecified and then using an abreviation that fits both is not really a good idea when documenting something.

[JonB]

@SGaist said in QFile::close() leads to SIGILL:

Undefined VS Unspecified and then using an abreviation that fits both is not really a good idea when documenting something.

100% !

[JonB]

@Christian-Ehrlicher said in QFile::close() leads to SIGILL:

Simply take a look at the godbolt assembler output and read the tooltip :)

Wow! Just wow! Well, I certainly do see how the compiler has gone out of its way to let me drop into a SIGILL when I fail to return something :)

[SeDi]

@Christian-Ehrlicher said in QFile::close() leads to SIGILL:

I would guess it's clang: https://godbolt.org/z/qGaKeM

You are right. Sorry for the delay, after setting the thread to "solved" I didn't ever look into it until I just now noticed this little red warning about unread messages :-)