Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!mit-eddie!ll-xn!ames!oliveb!sun!gorodish!guy From: guy%gorodish@Sun.COM (Guy Harris) Newsgroups: comp.lang.c Subject: Re: Defining TRUE and FALSE Message-ID: <23253@sun.uucp> Date: Sun, 12-Jul-87 05:31:09 EDT Article-I.D.: sun.23253 Posted: Sun Jul 12 05:31:09 1987 Date-Received: Mon, 13-Jul-87 00:47:57 EDT References: <13851@watmath.UUCP> <7460@elsie.UUCP> <13891@watmath.UUCP> Sender: news@sun.uucp Lines: 61 Keywords: true, false, boolean > There have been some interesting comments, all valid. Yes, in a > proper implementation > > #define TRUE 1 > #define FALSE 0 > > should work properly. The solution I offered was one that should > guarantee portability. Nope. If you assume that the implementation can get the definition of the "==" operator wrong to the extent that "0 == 0" does not evaluate to 1, and that to be safe you have to define TRUE as "0 == 0", you should also assume that it can get the definition of the "+" operator wrong so that "1 + 1" doesn't evaluate to 2. The definition of the "==" operator is pretty clearly spelled out in all descriptions of C; anybody who gets *that* wrong is capable of just about any screwup. Unless the quality of C implementations out there is *so* dismal that C cannot be taken seriously as a portable language for implementing software (in which case, you shouldn't implementing software in C if you intend to port it), writing code that "defends" against the possibility that an implementation of the language is fundamentally flawed is silly (*and* does not "guarantee portability" unless you defend against practically every screwup that can be imagined), nor does assuming that the implementation is *not* fundamentally flawed run the risk of unportability as you seem to be implying here. > I think, however, that lint is pretty picky if it flags an expression of > the form > > i = ( 0 == 0 ); > > which is perfectly valid if you read the grammar to the language. > Any decent compiler will simply fold this value into the appropriate > constant value. It's syntactically valid, but so what? That's not the point. "lint" complains about this if it is asked to "Apply a number of heuristic tests to attempt to intuit bugs, improve style, and reduce waste." The key words here are "heuristic" and "intuit". It is trying to detect code that is syntactically valid, and perhaps even semantically valid, but possibly wrong anyway. This test will pick up errors such as writing if (datum & MASK == VALUE) rather than if ((datum & MASK) == VALUE) to test whether a subfield of "datum" is equal to a particular value. (This could be considered an argument in favor of bitfields; with bitfields, you can directly express what you mean here, and not fact the possibility of getting the test wrong. You can't use bitfields in all cases - if the format of "datum" is externally imposed, you will probably need the mask, since the order in which bit fields are placed within structure is implementation-dependent.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com