[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/

[Douglas Gregor]

On Sep 27, 2011, at 4:24 PM, David Blaikie wrote:

> 
> 
> 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?

Yes, that's exactly the difference: NULL has had a proper meaning "for all time" in the C family of languages, but "bool" is far less entrenched in the C90 world.

	- Doug

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