https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126264
Vladislav Semykin <vladislav.semykin at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vladislav.semykin at gmail dot
com
--- Comment #2 from Vladislav Semykin <vladislav.semykin at gmail dot com> ---
Disclaimer.
I am not a maintainer or an active contributor,
but I found this bug report interesting, so I
would like to share my own understanding of the
situation.
Repro: https://godbolt.org/z/MK844YvTd
According the official documentation:
https://gcc.gnu.org/onlinedocs/gcc-16.1.0/gcc/Common-Attributes.html#index-error
the attributes error and warning expect a string
literal as their argument. When GCC encounters
something else (like NULL which is a macro and
which expands to ((void*)0)), it issues:
-------------------------------------------------
warning: 'error' attribute ignored [-Wattributes]
-------------------------------------------------
and then ignores the attribute entirely. The
compilation continues, and the function is
treated as a normal declaration, but linker gives
us an undefined reference because there is no body
for the _fail function.
Clang's approach is stricter syntax check -
attribute need to be a string literal, not a
pointer. While GCC just omits this, Clang gives
compilation error.
For real, I do not understand why MSVC does not
compiles, but ok, no matter.
---
>From my side I can suggest more stricter behaviour
like in Clang, because:
- compile-time error stops the build immediately
and clearly points to the exact issue;
- the attribute contract explicitly says
"string literal" by this line: warning ("message").
Passing a null pointer constant is semantically
wrong; it is not a valid message. Treating it
as an error is more consistent with the rules
for attributes;
- if you accidentally write error(NULL) or warning(NULL)
and also define the function, the attribute is simply
ignored and you get no diagnostic at all (except the
ignored-attribute warning, which may be overlooked).
This could hide intended compile-time checks.
Happy to make a patch, if it would be useful.
---
Waiting for comments from the maintainers or
anyone with more expertise on this matter I would
appreciate your thoughts.
