https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
frankhb1989 at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |frankhb1989 at gmail dot com
--- Comment #20 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #11)
> I hate that behaviour. Having to use !__is_identifier(__builtin_launder) is
> confusing (and not just to me, but to developers of LLVM's own libc++, who
> I've had to explain the problem to).
>
> But consistency with Clang is probably more important than making
> __has_builtin behave sanely.
What if breaking that insane compatibility? How does it make things worse?
`__has_builtin` is expected to be OK even with false negative results (but
surely not false positive ones). Is there any real examples showing that
relying on something like `!__has_builtin(__builtin_offsetof)` necessary for
the needs in practice?
Note that there is already no warranty by the standard with the use of `__`,
and I don't ever find reasons that things like `int __builtin_abort = 0;`
should work besides the leaked implementation details. Such abuse seems not
documented at all. Even such use is eventually guaranteed to work, the extent
should be justified by `__is_identifier`, with nothing to do with the
`__builtin_` prefix.
