warning: declaration does not declare anything / error: no member named 'LOW' in 'STRUCT'

Clang Frontend
1

Hello List,

Given the following piece of code.

typedef union {
  struct {
    unsigned char LOW;
    unsigned char HIGH;
  };
  unsigned short SHORT;
} UNION;

typedef struct {
  UNION; // <-- use of type only
  union {
    unsigned char FOO;
  };
} STRUCT;

STRUCT Variable;

void Function () {
  Variable.LOW = 1;
}

This code compiles without any error using gcc 7.2 (When compiling with
-ansi -pedantic I get the warning "ISO C90 doesn't support unnamed
structs/unions". If I add -std=c11 the warning disappears)

If I use clang 6.0 to compile (clang -c), I get the following output.

file.c:10:2: warning: declaration does not declare anything
[-Wmissing-declarations]
        UNION; // <-- use of type only
        ^~~~~
file.c:19:11: error: no member named 'LOW' in 'STRUCT'
        Variable.LOW = 1;
        ~~~~~~~~ ^
1 warning and 1 error generated.

The output is the same if add -std=c11/-std=gnu11 to the command line.

So my Question is. Is there a compiler switch to avoid this error? Or
would it help to use clang 7.0?

Thx
Frank

2

Declaring an anonymous union like that non-standard; you need to pass -fms-extensions.

-Eli

3

Would it make sense to add a -fplan9-extensions flag, to enable support for this without enabling all the other MS extensions that we support?

4

Adding a separate flag to control this is probably fine. Not sure about the name fplan9-extensions; in gcc, I think that includes some other extensions we don't implement.

-Eli

5

The Plan9 C extensions are described here: http://doc.cat-v.org/plan_9/4th_edition/papers/compiler

… in which we find “The most important and most heavily used of the extensions is the declaration of an unnamed substructure or subunion.” (Though it is worth observing that our extension here is less powerful than the Plan9 C extension in a couple of ways.)

I think using -fplan9-extensions for “the set of Plan9 C extensions that we support” seems appropriate, even if we don’t support all of them, and if that flag means something different from what it means to GCC as a result. (And it’s worth noting that we already support most of the other extensions as either GNU extensions or as part of C99.)