[cfe-commits] r140650 - in /cfe/trunk: include/clang/AST/ lib/ARCMigrate/ lib/AST/ lib/Frontend/ lib/Rewrite/ lib/Sema/ test/Index/ test/SemaObjC/ tools/libclang/

[David Blaikie]

On Tue, Sep 27, 2011 at 4:16 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Sep 27, 2011, at 3:48 PM, Eli Friedman wrote:
>
> > On Tue, Sep 27, 2011 at 3:38 PM, Douglas Gregor <dgregor at apple.com>
> wrote:
> >> Author: dgregor
> >> Date: Tue Sep 27 17:38:19 2011
> >> New Revision: 140650
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=140650&view=rev
> >> Log:
> >> When 'bool' is not a built-in type but is defined as a macro, print
> >> 'bool' rather than '_Bool' within types, to make things a bit more
> >> readable. Fixes <rdar://problem/10063263>.
> >
> > Is it actually safe to assume that bool is defined to _Bool?  It's
> > probably not hard to find code that has constructs like "#define bool
> > int"...
>
> *sigh*
>
> You are right, of course. I'm working on threading this through.
>

When is bool not a builtin type but defined as a macro? C? At least in C99
it's well defined, but I suppose C99's not exactly universally adopted.

Anyway, my point was to draw a comparison between this and the NULL macro -
which we seem to assume is actually the real implementation provided NULL
macro (& suggest it for null pointers in C++03 if it's defined in a TU). I
suppose NULL exists in the standards of all languages clang supports whereas
bool exists in all except the pre-C99 variants, which leaves us open to
needing to support alternative definitions?

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