Re: [RFA]: BOOL coding standards (Was: Problemwith+numberWithBool:?)

[David Ayers]

Kazunobu Kuriyama wrote:
> Nicola Pero wrote:
> > You could think that since BOOLs work as C truth values, if count is > 0,
> > this is YES, if it's 0, it's NO (I'm sure you've seen enough C coders to
> > know they love being "clever" in that way with C truth values), so the
> > code should work, but unfortunately it doesn't.
> Don't attribute it to C programmers. Sane C programmers don't (want to,
> at least) do anything like above.  Apart from the insane, they never try
> to devise a boolen type by themselves once they know the language well,
> though they prefer defining convenience macros such as #define FALSE (0)
> and #define TRUE (1) in their header file.  C99?  They cleverly leave
> that type to the compiler!  We should know this makes a huge difference.

Questioning the sanity of programmers, that had this misconception 
(which includes me, yet I'm speaking only for myself) doesn't strike me 
as productive contribution.  Please excuse that my argumentation was a 
bit jumpy and possibly misleading.  So let me try to rephrase to 
hopefully satisfy everyones need for correctness and hopefully end this 
part of the thread.

Due to the standard C conversion rules, which may truncate the higher 
order bytes, code must insure to explicitly convert any C truth values 
into the valid BOOL values if either YES or NO.

Non the less, I'd like to point out, that it seems that all these sane C 
programmers were either unable or unwilling to point out this issue when 
I asked for a "license" to treat C truth values specially wrt BOOL, save 
Richard.

> Apart from their being actually clever or not, it's responsibility for
> Objective C how to define BOOL.  The fault lies only in the fact that BOOL
> has not been made a built-in Objective C type so far (the spec defines it
> as if it were, not explicitly stated like this though).  Without having
> compilers exactly know the meaning of boolean, what can we expect them to
> do with it?  They are only told BOOL is a kind of short integer!  Wrong
> usage of BOOL must attribute to careless ObjC programmers, neither C
> programmers nor compilers.  IOW, that's our problem.

I'd say uninformed rather than careless, but maybe some sane C 
programmer can offer a patch to our coding conventions to educate us 
carelessly insane ObjC developers, by correctly and clearly stating and 
demonstrating the issue.

I'd appreciate if we could get back to the discussion on whether we 
should have a public macro to warn/assert about the correct values of 
BOOL parameters and return values, so that other carelessly insane 
developers may be educated.

I have no objections to stick with isYES(), but maybe a simple 
is()/_is() may be less bulky than my previous alternatives and won't be 
as hard to parse in comparisons involving NO.  I'd be in favor of 
emitting a warning and "BOOLifying*" by default and possibly raising 
with NDEBUG defined (i.e. when compiled with debug=yes).  If some think 
this is too harsh because there are too many carelessly insane 
developers that have produced legacy code that doesn't take care to 
convert, I'd be fine with only emitting warnings.

Cheers,
David

* comparing with "!= NO" and returning the result.