3

Trying to turn up some warning levels on a C codebase that also builds as C++. I'm giving Visual Studio a shot (for some reason).

Got a warning about setjmp interactions, despite not seeing any relevant destructors. so I did a test:

#include <setjmp.h>

struct X { int y; };

int main() {
    struct X x;

    jmp_buf buf;
    if (setjmp(buf) == 0) {
        longjmp(buf, 1);
    } else {
        // whatever.
    }
}

Enabling the warning on the command-line:

C:\wherever>cl /we4611 test.cpp

test.cpp test.cpp(9): error C4611: interaction between '_setjmp' and C++ object destruction is non-portable

This seems like an extremely useful warning--if it was warning me about crossing C++ destructor code. But that's a POD type. There shouldn't be any destructor code.

Am I missing something here, or did they botch this warning to the point of making it basically "you used setjmp in a C++ program"?

  • Does the warning mysteriously vanish if you enable optimization? (This particular diagnostic may be sensitive to whether the compiler has _noticed_ that a type is POD, and it might not be so careful about noticing in the "minimize compilation time" default mode.) – zwol Jul 29 '17 at 02:53
  • @zwol With full optimization (`cl /we4611 /Ox test.cpp`) it still gives the warning. :-( – HostileFork says dont trust SE Jul 29 '17 at 03:01
  • 1
    I'm afraid that's me out of ideas, then. I agree with your assessment that the warning is worthless if it triggers on PODs. – zwol Jul 29 '17 at 03:14
  • @zwol Oh well, thanks anyway. I [added a suggestion](https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/20354494) on the MS site. – HostileFork says dont trust SE Aug 01 '17 at 02:52

1 Answers1

1

did they botch this warning to the point of making it basically "you used setjmp in a C++ program"?

Looks to be the case.

I'd probably classify it as a bug, myself. But it was easier to make a suggestion on the Microsoft website. Suggestions can be voted on, there...