This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/60304] Including <atomic> disables -Wconversion-null
- From: "manu at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 24 Oct 2014 10:38:56 +0000
- Subject: [Bug c++/60304] Including <atomic> disables -Wconversion-null
- Auto-submitted: auto-generated
- References: <bug-60304-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #9 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #5)
> Well, of course the user can always explicitly include, eg, <cstdbool>, thus
> it seems that the real underlying issue is that the system-headers machinery
> should not be fooled by things like this in a system header... or should it?
> The define is rather interesting...
>
> #define false false
>
> I'm adding in CC Dodji too...
In the case of NULL we do:
source_location loc =
expansion_point_location_if_in_system_header (input_location);
however, we do not do it in the case of 'false' (because we do not think it
should be a macro, but it actually is). Perhaps we should do it, is there a
downside to it?