From: Martin Ambuhl Newsgroups: comp.os.msdos.djgpp Subject: Re: BOOL as char/int Date: Tue, 13 Apr 1999 23:29:31 -0400 Content-Transfer-Encoding: 8bit References: <7ev4na$49a$1 AT lola DOT ctv DOT es> X-Posted-Path-Was: not-for-mail X-Accept-Language: en Content-Type: text/plain; charset=iso-8859-1 X-ELN-Date: 14 Apr 1999 03:29:39 GMT X-ELN-Insert-Date: Tue Apr 13 20:35:41 1999 Organization: Nocturnal Aviation Lines: 41 Mime-Version: 1.0 NNTP-Posting-Host: dialup-209.244.177.249.newyork2.level3.net Message-ID: <37140B9B.E01D9726@earthlink.net> X-Mailer: Mozilla 4.51 [en] (Win95; I) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Rafael García" wrote: > > Look at this: > > #include > > typedef char /*int*/ BOOL; > #define TRUE 1 > #define FALSE 0 > > main() { > BOOL flag=(BOOL)isupper('E'); > puts(flag?"*TRUE*":"*FALSE*"); > return 0; > } > > It fails with BOOL as char, but works as int > Can someone explain this reasonably? > It works well with Borland 1) Always #include when using functions prototyped there. 2) the is* family is defined to "return nonzero(true) if and only if the value of the argument c conforms to the description of the function." (7.3.1) isupper('E') returns 512, which is non-zero, but when assigned to a char is subject to the implementation-defined behavior when char is signed or reduction by modulus for unsigned char described in 6.2.1.2. In any case, 512 % 256 = 0. There is hardly any reason to define FALSE or TRUE (and your definition is flawed) or to use char as the type since all standard C functions that return true/false type answers return ints except for those which return NULL pointers on failure. > I have been using this typedef for years and it seems standard, robust, > good, pretty, simple, near-machine, fast, compact... > It seems gods of chaos are conquering the world of computing -- Martin Ambuhl (mambuhl AT earthlink DOT net) Note: mambuhl AT tiac DOT net will soon be inactive