Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pacbell!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: C Style Message-ID: <4546@ihlpf.ATT.COM> Date: 26 Apr 88 23:43:44 GMT References: <11216@brl-adm.ARPA> <2111@chinet.UUCP> <4403@garfield.UUCP> <226@hotlr.ATT> <130@obie.UUCP> <5981@utcsri.UUCP> <1982@ubc-cs.UUCP> <126@atpal.UUCP> <2823@mmintl.UUCP> <255@oink.UUCP> <3583@haddock.ISC.COM> <20126@think.UUCP> <3592@haddock.ISC.COM> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 20 In article <3592@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes: >I think a more important reason is that the boolean operators such as "<" and >"&&" are already guaranteed to return normalized boolean values (i.e. truth is >denoted by 1). Requiring the isXXX functions to do likewise would follow the >principle of least astonishment. This is a matter of opinion. Personally, I would rather have the isXXX macros be required to return their argument if true, since this conveys more useful information than simplay a TRUE (1) or FALSE (0) value (BTW, this might not be possible with the isascii macro). Also, I would rather have all bits set to represent TRUE (such as two's complement for -1) instead of 1, since I can use the bitwise operators on boolean values most effectively this way (I'm not expecting this to happen due to prior art with < and &&, but one can hope). -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_