gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Malmberg
Subject: Re: [RFA]: BOOL coding standards (Was: Problem with+numberWithBool: ?)
Date: Sun, 01 Feb 2004 04:55:31 +0100

Richard Frith-Macdonald wrote:
> On 31 Jan 2004, at 09:08, David Ayers wrote:
> > OK folks,
> >
> > it's pretty clear that some of us consider accepting on non-YES-NO
> > values for BOOL as "non-conforming" of s strict interpretation of the
> > "type" BOOL, yet we have clear indication in a reference documentation
> > that we (and people developing on top of the API) should not rely on
> > [someValue boolValue] == YES to work.
> 
> I think the documentation strongly implies that the people writing it
> also consider the case of some methods returning non YES/NO values in a
> BOOL to be a bug/misfeature, as they warn about those cases where it
> happens.

If they thought it was a bug, they could "fix" it. I read it as a
warning intended to make it clear that BOOL:s may have values other than
YES and NO since (obviously :) this isn't as clear as one would hope.

[snip]
> As long as we
> don't have proper boolean support  in the compiler (a true boolean with
> warnings generated if
> an attempt is made to assign a non-YES/NO value to a boolean without an
> explicit cast)
[snip]

I sense a deep philosophical disagreement here. A true boolean should
not, IMHO, behave that way. Fortunately, we do have a true boolean type
in c99 (_Bool), and it behaves as I expect it to, ie. there are no
warnings for assignments, and it handles truth values correctly. Eg.:

_Bool bool=5;
and
_Bool bool=aPointerThatIsntNULL;

both set the bool to true (which "reads back" as 1).

[snip]
> Making a coding standard about this was not my idea ... 

Note that this is a coding standard, not a style guide. I don't care
much about which style you use, _as_long_as_ the result is correct. The
patch was intended to explain what "correct" means wrt BOOLs in GNUstep.
I've attached a revised patch that will hopefully make this clearer.

- Alexander Malmberg
Index: Documentation/coding-standards.texi
===================================================================
RCS file: 
/cvsroot/gnustep/gnustep/core/base/Documentation/coding-standards.texi,v
retrieving revision 1.8
diff -u -r1.8 coding-standards.texi
--- Documentation/coding-standards.texi 22 Sep 2003 03:00:21 -0000      1.8
+++ Documentation/coding-standards.texi 1 Feb 2004 03:38:53 -0000
@@ -63,6 +63,7 @@
 * Variable Declaration::        
 * Object Persistance::          
 * Contributing::                
+* BOOLs::
 @end menu
 
 @c ******************************************************************
@@ -348,7 +349,7 @@
 
 
 @c ******************************************************************
address@hidden Object Persistance, Contributing, Variable Declaration, Top
address@hidden Object Persistance, BOOLs, Variable Declaration, Top
 @section Object Persistance
 
 The standard method of saving and restoring object information in GNUstep
@@ -361,7 +362,18 @@
 should be read.
 
 
address@hidden Contributing,  , Object Persistance, Top
address@hidden 
******************************************************************
address@hidden BOOLs, Contributing, Object Persistance, Top
address@hidden BOOLs
+
+When using BOOL values, care should be taken to ensure to ensure that all
+non-zero values are treated as true.
+
+Methods that return BOOL values should return only YES or NO to avoid
+triggering problems in code that treats only YES as true.
+
+
address@hidden Contributing,  , BOOLs, Top
 @section Contributing
 
 Contributing code is not difficult. Here are

reply via email to

[Prev in Thread] Current Thread [Next in Thread]