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
