Page MenuHomeFreeBSD

llvm9 wont allow enum definition inside anon-struct
AcceptedPublic

Authored by sjg on Apr 17 2020, 7:05 PM.

Details

Summary

Define enum socket_qstate outside of struct socket
to appease llvm-9.0 clang++

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 30568
Build 28313: arc lint + arc unit

Event Timeline

Can you provide some more information on the exact error you saw? I'm 99.9% sure we successfully compiled these sources with LLVM 9.

Of the 100 .meta files, this is the one I didn't save. The error with clang++ was "cannot declare types inside an anonymous struct."

I was able to replicate it locally using llvm's c++ 9.0.1 and defining _WANT_SOCKET prior to including the header file:

Code:

extern "C"
{
#include <sys/types.h>
#define _WANT_SOCKET
#include <sys/socketvar.h>

static struct socket blah;

void do_something(void) {
    blah.so_oobmark = 0;
}
}

#include <iostream>
using namespace std;

int main() {
std::cout << "Hello, world!\n";
do_something();
return (0);
}

Results:

[jtl@jonathan1 /tmp]$ c++ -o temp temp.cpp 
In file included from temp.cpp:5:
/usr/include/sys/socketvar.h:125:4: error: types cannot be declared in an
      anonymous struct
                        enum {

Looking at the clang code, it looks like this nested definition is allowed if MS extensions are enabled. And, indeed, it compiles and runs correctly:

[jtl@jonathan1 /tmp]$ c++ -fms-extensions -o temp temp.cpp 
[jtl@jonathan1 /tmp]$ ./temp 
Hello, world!

Just, don't actually try to use the enum values:

[jtl@jonathan1 /tmp]$ c++ -fms-extensions -o temp temp.cpp 
temp.cpp:10:22: error: use of undeclared identifier 'SQ_NONE'
    blah.so_qstate = SQ_NONE;
                     ^
1 error generated.

I'm tempted to say this is an LLVM bug. After all, C code should work correctly inside an extern "C" block. But, I'm not entirely sure this will be high on someone's list to fix.

If the -fms-extensions workaround doesn't work for you, I guess I'm OK with the proposed change. Its just too bad we can't take full advantage of C features due to C++ compatibility problems...

rpokala added a subscriber: rpokala.

This seems reasonable.

This revision is now accepted and ready to land.Apr 18 2020, 1:07 AM