[cfe-dev] null pointer literals, warnings, and fixups

David Blaikie dblaikie at gmail.com
Thu Aug 25 09:36:22 PDT 2011


>
> I don't think these warnings would be suitable for Clang.
>

Even suggesting nullptr in C++11? With things like the bool warning, NULL*
used in non-pointer contexts, etc already, this seems like a fairly logical
continuation/generalization of that - or would you say that, even in C++11,
that it's clear that false is probably not intended as a pointer literal but
still likely that someone should use 0/NULL/etc rather than nullptr?

Or perhaps these existing warnings are more a case of GCC compatibility, but
not really the direction you'd prefer to clang to go in if it weren't for
GCC's legacy.

* GCC built the whole __null construct to help catch these issues. Now that
we have a null pointer type we don't even have to do that - we just treat it
as the "proper nullptr literal" & warn about anything else (& warn about
NULL usage).

[hmm, on the 0/NULL case in C++98 - does clang support the possibility of
alternative fixits? ("make this change or this change") though of course
that'd reduce/remove the easy migration benefit in C++98 code]



> Such style-checking transformations belong in a separate tool (e.g., like
> the ARC migrator).
>

I'll have to look into how the ARC migrator works - both for the migration &
for keeping code style consistent in the long term. That's part of what I
was getting at - I turn on the "use nullptr" warning & then I'm never going
to accidentally end up with weird uses of NULL or 0/false/etc in my code (or
even in llvm's code if there was a nice way to implement some C++98
equivalent), ideally.


>
> [curiously - clang -cc1 foo.cpp doesn't enable colored diagnostics by
> default (when run on a terminal capable of color - where clang foo.cpp does
> use color). Is that by design?]
>
>
> Yes. clang -cc1 is just the internal interface to the compiler. The driver
> makes all of the interesting decisions, such as detecting whether the
> terminal supports color.
>

Makes sense. Thanks,

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110825/6e2d6a57/attachment.html>


More information about the cfe-dev mailing list