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"
syntaxform 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
