Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Writing readable code
Message-ID: <6057@brl-smoke.ARPA>
Date: Sun, 5-Jul-87 15:47:37 EDT
Article-I.D.: brl-smok.6057
Posted: Sun Jul  5 15:47:37 1987
Date-Received: Sun, 5-Jul-87 22:41:54 EDT
References: <13008@topaz.rutgers.edu> <1941@zeus.TEK.COM> <849@tjalk.cs.vu.nl>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 27

Let me explain by example why
	if ( bool_expr == TRUE )
is dangerous (it should be obvious why it's redundant),
so that
	if ( bool_expr )
should be preferred.  There is no corresponding problem in C with
	if ( bool_expr == FALSE )
although I would recommend
	if ( !bool_expr )
instead.  As other have remarked, the proper use for symbolic constants
TRUE and FALSE is as values to be assigned to variables (or function
returns) that are considered to be inherently Boolean in nature.

(Actually, I so strongly consider treating Boolean objects as inherent
primitive types to be important that my own definitions are lower-case,
to appear just like language keywords.)

EXAMPLE:

The original UNIX System V Release 2.0 definitions in  were
	#define feof(p)		((p)->_flag & _IOEOF)
	#define ferror(p)	((p)->_flag & _IOERR)
These are supposed to be treated as Boolean expressions, but their
TRUE values are NOT 1.  In my version of  I changed these to
	#define feof(p)		(((p)->_flag & _IOEOF) != 0)
	#define ferror(p)	(((p)->_flag & _IOERR) != 0)
for safety's sake.