RE: Proposal: Add more compile-time asserts to expose inconsistencies.

Hi Andres,

>>> As far as I can tell we should be able to use the prototype based approach in all the cases where we currently use the "negative bit-field width" approach?

>> ...
>> But I did not refactor existing code to use the new way because I was 
>> fearful that there might be some subtle reason why the 
>> StaticAssertStmt was deliberately made that way (e.g. as do/while), 
>> and last thing I want to do was break working code.

>That'll just leave us with cruft. And it's not like this stuff will break in a subtle way or such....

FYI - I did try, per your suggestion, to replace the existing StaticAssertStmt to also use the same fallback "extern" syntax form as the new StaticAssertDecl, but the code broke as I suspected it might do:

====================
path.c: In function 'first_dir_separator':
../../src/include/c.h:847:2: error: expected expression before 'extern'
  extern void static_assert_func(int static_assert_failure[(condition) ? 1 : -1])
  ^
../../src/include/c.h:849:2: note: in expansion of macro 'StaticAssertStmt'
  StaticAssertStmt(condition, errmessage)
  ^
../../src/include/c.h:1184:3: note: in expansion of macro 'StaticAssertExpr'
  (StaticAssertExpr(__builtin_types_compatible_p(__typeof(expr), const underlying_type), \
   ^
path.c:127:11: note: in expansion of macro 'unconstify'
    return unconstify(char *, p);
           ^
====================

Kind Regards.
---
Peter Smith
Fujitsu Australia