Re: Problem with +numberWithBool: ?

[Richard Frith-Macdonald]

On 30 Jan 2004, at 15:14, Alexander Malmberg wrote:

> Richard Frith-Macdonald wrote:
> > On 30 Jan 2004, at 11:26, Helge Hess wrote:
> > > On Jan 29, 2004, at 2:12 PM, Richard Frith-Macdonald wrote:
> > > > Booleans in objc can be YES or NO ... this is not the same thing as
> > > > true/false in C/ObjC conditionals where 0 is false and anything
> > > > non-zero is true.
> > >
> > > Such an assumption (which is probably not backed by the ObjC "spec")
> >
> > I have noticed that when you say 'probably' you seem to mean 'I 
> > haven't
> > checked'  :-)
> >
> > Page 178 of the NeXTstep reference, section headed Defined Types ...
> >
> > 'BOOL   A boolean value, either YES or NO'
>
> But this isn't a spec, and it tells.


Helge wrote spec in quotes ... I'm pretty sure that he is aware that 
there is no
formal specification of ObjC in terms of a standards document, and that 
the
ObjC manual NeXT produced has been the (informal) spec for many years.
The alternative view is that the compiler is the language spec ... I 
don't
really like that one.  It would be nice if we could produce a new spec 
and
get the compiler people to adopt it .. if GNUstep had major influence 
on that
document it might give Apple more incentive to provide some help in 
ensuring
that updates to the compiler are done in sync with both apple and gnu 
runtimes?

> That statement is way too vague to
> be useful when implementing things.

It's true this does not tell a compiler writer how to implement BOOL, 
but
in terms of its intended usage in the ObjC lanugage it's very precise in
that it tells you that the BOOL type is intended to be for a boolean 
value
and that such a value should be either 'YES' or 'NO'.

> Anyway, the intent here is
> irrelevant. objc/objc.h has:
>
> typedef unsigned char  BOOL;
>
> and, in practice, that's what matters.
>
> > I'm sure I've seen arguments about this before
>
> Do you have a link to this prior discussion (if it was public)?
>
> > -  I judged the
> > consensus to be that the
> > BOOL type is intended to be boolean, and the fact that it's stored as 
> > a
> > char is an
> > implementation detail.
>
> It isn't an implementation detail since it means that BOOL isn't a true
> boolean type.

Well, I guess you could call it a bug rather than an implementation 
detail,
but I wouldn't be so bold:-)

Compare this with c99's _Bool, which is a true boolean
> type:
>
> #include <objc/Object.h>
> int main(int argc,char **argv)
> {
>         int i=5;
>         BOOL objc_bool;
>         _Bool c99_bool;
>
>         objc_bool=i;
>         c99_bool=i;
>         printf("objc_bool=%i  c99_bool=%i\n",objc_bool,c99_bool);
>         return 0;
> }
>
> This will print:
>
> objc_bool=5  c99_bool=1

Perhaps the compiler may someday be updated so that objc.h says
typedef c99_bool        BOOL;
so that the implementation better matches the language spec.

I guess by the time gcc managed to implement a proper boolean
there was a lot of legacy code around making an update difficult.