Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Why _Bool was not defined as enum in C99?
Date: Wed, 14 Sep 2016 19:04:39 -0700
Organization: None to speak of
Lines: 72
Message-ID: <lna8f95360.fsf@kst-u.example.com>
References: <6b5aa241-0498-4e41-993b-a1ed445effb0@googlegroups.com> <kfnd1k7jton.fsf@x-alumni2.alumni.caltech.edu> <lntwdj5lv2.fsf@kst-u.example.com> <kfnmvjaiwbw.fsf@x-alumni2.alumni.caltech.edu> <02a1a24e-5ead-486c-8397-e68a2a79f8f7@googlegroups.com> <8760pynx50.fsf@bsb.me.uk> <lnd1k65hmr.fsf@kst-u.example.com> <87twdim428.fsf@bsb.me.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="7230"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Kr6PVf24r1yCxOEzIgV4c"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:bEglRg7hVUb85Aoxl8wYFanl4VA= sha1:GL4eDCNKlfJ+jJ7wYNgVtQWX6Qw=
Xref: csiph.com comp.lang.c:93511

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> supercat@casperkitty.com writes:
>> [...]
>>>> if the Committee had simply used an enumerated type, the
>>>> semantics of enumerated types would--by definition--have fit
>>>> perfectly.
>>>
>>> You'd have expressions E such that
>>>
>>>   if ((_Bool)E)
>>>
>>> and
>>>
>>>   if (E)
>>>
>>> behave differently.
>>>
>>> <snip>
>>
>> Not if the hypothetical enumerated _Bool has the same conversion
>> semantics as the built-in _Bool that was actually added in C99.
>> I don't think anyone is suggesting just adding the equivalent of
>> a predefined
>>
>>     typedef enum { false, true } _Bool;
>>
>> and leaving it at that.
>
> Actually, I thought that was exactly what the OP was asking about.  And
> it sounds like it is what supercat was talking about in the message I
> replied to.  That's how I read "if the Committee had simply used an
> enumerated type" and the idea that the semantics would be right by
> definition.

Ok, I might have misinterpreted what others were saying.

> But if it's a special enumeration with its own conversion semantics, how
> do you know that is *not* how _Bool is implemented?  Or, to put it
> slightly differently, what would give the game away so you could say
> that it's a special enumerated type with its own semantics?

For the type itself, I can't think of a way to detect the difference.
But you could certainly detect the difference in the way false
and true are defined (assuming that the type name _Bool and the
constants false and true are all predefined by something resembling
an enumerated type definition).

BTW, I've been wondering why bool is defined as a macro rather than
as a typedef.  My best guess is that it's to allow for code that
(a) defines its own "bool" somehow, but (b) indirectly, and probably
unintentionally, includes <stdbool.h>.  If you have some pre-C99 code
that has, for example:

    typedef enum { false, true } bool;

then you can change it to:

    #undef bool
    #undef false
    #undef true
    typedef enum { false, true } bool;

and it will still compile correctly even if <stdbool.h> is present.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"