| Author |
Message |
|
Paul Lo
#1 / 12
|
 coding anti-anti-standards [was: coding anti-standards]
Quote: (Albert Hui) writes:
>> >> #define TRUE (0==0)
>> >> #define FALSE (!TRUE)
>> >#define TRUE 1
>> >#define FALSE 0
>> How about the "standard" hack...? :)
>> #define TRUE '/'/'/'
>> #define FALSE '-'-'-'
Well, that'd work, of course, but I'd probably do it like this so as to remove the assumption that "true" was 1: :-) #define TRUE (('/'/'/')==('/'/'/'))
#define FALSE (!TRUE)
Sent from Oregon Telcom
|
| Thu, 20 Feb 1997 02:06:18 GMT |
|
 |
|
John William Chamble
#2 / 12
|
coding anti-anti-standards [was: coding anti-standards]
[ long discussion of macros to simulate a Boolean type deleted ]
Quote: >#define TRUE (('/'/'/')==('/'/'/'))
>#define FALSE (!TRUE)
Why not just remember that 0 is false, and nonzero is true? Anyone who can't read
if(foo)
and
if(!bar)
probably should be using another language anyway.
--
* Billy Chambless University of Southern Mississippi
* "If you lie to the compiler, it will get its revenge." Henry Spencer
|
| Fri, 21 Feb 1997 02:33:36 GMT |
|
|
|
Hans Friedrich Steffa
#3 / 12
|
coding anti-anti-standards [was: coding anti-standards]
Quote: >Why not just remember that 0 is false, and nonzero is true?
>Anyone who can't read
> if(foo)
> and
> if(!bar)
>probably should be using another language anyway.
Perhaps, the one shouldn't use any computer-language, as this problem isn't a nativ c-problem. Hans Friedrich Steffani
--
0721 / 608-6008
|
| Fri, 21 Feb 1997 14:16:57 GMT |
|
|
|
William J. Eva
#4 / 12
|
coding anti-anti-standards [was: coding anti-standards]
: >Why not just remember that 0 is false, and nonzero is true?
: >Anyone who can't read
: > if(foo)
: > and
: > if(!bar)
: >probably should be using another language anyway.
: Perhaps, the one shouldn't use any computer-language, as this problem
: isn't a nativ c-problem.
Correct. Such a person should shun all computer languages,
and stick with COBOL. (Gosh darn it, where _did_ I put my asbestos
underwear?)
-- Bill Evans
: Hans Friedrich Steffani
: --
: 0721 / 608-6008
|
| Fri, 21 Feb 1997 22:52:26 GMT |
|
|
|
John William Chamble
#5 / 12
|
coding anti-anti-standards [was: coding anti-standards]
Quote: >Perhaps, the one shouldn't use any computer-language, as this problem
>isn't a nativ c-problem.
Possibly. But I was mostly thinking of people ho learned to program in a language like Pascal that has a defined Boolean type and try to simulate that mby macros in c. I used Booleans in Pascal, yet I don't really miss them in C.
--
"Obviously unlike you people, I don't have time to edit the newsgroups line
|
| Sat, 22 Feb 1997 03:05:43 GMT |
|
|
|
Paul Lo
#6 / 12
|
coding anti-anti-standards [was: coding anti-standards]
Quote: William Chambless) writes:
>> [ long discussion of macros to simulate a Boolean type deleted ]
>> >#define TRUE (('/'/'/')==('/'/'/'))
>> >#define FALSE (!TRUE)
>> Why not just remember that 0 is false, and nonzero is true?
I was kidding about ('/'/'/')==('/'/'/'). Didn't you see the smiley face? Quote: >> Anyone who can't read >> if(foo)
>> and
>> if(!bar)
>> probably should be using another language anyway.
You'll get no objection from me. if (bar == TRUE) and if (bar == FALSE) would be really wretched. I was saying that this is what I would have had to do to quiet Lint if I had typedefed Boolean as an enumeration of TRUE and FALSE. That's why I #define TRUE and FALSE.
Sent from Oregon Telcom
|
| Sat, 22 Feb 1997 11:31:24 GMT |
|
|
|
Kurt Watz
#7 / 12
|
coding anti-anti-standards [was: coding anti-standards]
Quote: >On the topics of hacks like this, has anybody put together any type of
>system that intentionally goes against all the common C assumptions
>but is still valid ANSI C code? Things like assuming the null pointer
>and the integer 0 have the same internal representation, "char *" can
>be used instead of "void *", etc. I'm sure such a beast would break
>lots and lots of C code...
First, the two assumptions you give as expamles are not "in the same class". While you cannot assume that the null pointer and the integer - have the same internal representation, you can safely assume that a char * can be used instead of a void *. Second, I cannot see how not assuming something when writing C
code that is still "vaild" (I assume you mean strictly conforming)
ANSI C code can break that code. Assuming something that is not
guarranteed by the standard "invalidates" the code, so not
assuming anything that is not guarranteed is neccessary to earn
the attribute "valid", imho.
From your last sentence I get the expression that you are talking
about an implementation of the C language, not about "ANSI C code".
If it is a confroming implementation, it will not break strictly
conforming programs (This is how a conforming implementation
is defined as far as I can remember).
--
| Kurt Watzka Phone : +49-89-2180-2158
|
| Sun, 23 Feb 1997 16:23:01 GMT |
|
|
|
Lawrence Kir
#8 / 12
|
coding anti-anti-standards [was: coding anti-standards]
Quote:
>[ long discussion of macros to simulate a Boolean type deleted ]
>>#define TRUE (('/'/'/')==('/'/'/'))
>>#define FALSE (!TRUE)
>Why not just remember that 0 is false, and nonzero is true?
>Anyone who can't read
> if(foo)
> and
> if(!bar)
Yes, it very bad form to compare against FALSE and especially TRUE. But TRUE and FALSE are created for assignment, not comparison. --
-----------------------------------------
-----------------------------------------
|
| Sat, 22 Feb 1997 00:50:59 GMT |
|
|
|
J. Daniel Smi
#9 / 12
|
coding anti-anti-standards [was: coding anti-standards]
Quote:
>(Albert Hui) writes: >>>[...] >>> How about the "standard" hack...? :) >>> #define TRUE '/'/'/'
>>> #define FALSE '-'-'-'
>Well, that'd work, of course, but I'd probably do it like this so as to
>remove the assumption that "true" was 1: :-)
>#define TRUE (('/'/'/')==('/'/'/'))
>#define FALSE (!TRUE)
On the topics of hacks like this, has anybody put together any type of system that intentionally goes against all the common C assumptions but is still valid ANSI C code? Things like assuming the null pointer and the integer 0 have the same internal representation, "char *" can be used instead of "void *", etc. I'm sure such a beast would break lots and lots of C code... Dan
--
====================== message is author's opinion only ======================
J. Daniel Smith Bristol Technology Inc., Ridgefield, Connecticut (USA)
FTP: ftp.bristol.com WWW: http://www.bristol.com
|
| Sun, 23 Feb 1997 09:12:16 GMT |
|
|
|
Alex Ram
#10 / 12
|
coding anti-anti-standards [was: coding anti-standards]
Quote:
> [ long discussion of macros to simulate a Boolean type deleted ]
> >#define TRUE (('/'/'/')==('/'/'/'))
> >#define FALSE (!TRUE)
> Why not just remember that 0 is false, and nonzero is true?
> Anyone who can't read
> if(foo)
> and
> if(!bar)
> probably should be using another language anyway.
Fine, but this is NOT the case where TRUE/FALSE are useful. Which one is more readable:
return (some arbitrary non-zero constant like 1, or -1, or 42);
or
return TRUE;
?
--
Louisiana Tech University, BSEE/Sr * These opinions are probably mine
|
| Fri, 21 Feb 1997 06:43:32 GMT |
|
|
|
Martin Sohni
#11 / 12
|
coding anti-anti-standards [was: coding anti-standards]
: >On the topics of hacks like this, has anybody put together any type of
: >system that intentionally goes against all the common C assumptions
: >but is still valid ANSI C code? Things like assuming the null pointer
: >and the integer 0 have the same internal representation, "char *" can
: >be used instead of "void *", etc. I'm sure such a beast would break
: >lots and lots of C code...
: Second, I cannot see how not assuming something when writing C
: code that is still "vaild" (I assume you mean strictly conforming)
: ANSI C code can break that code. Assuming something that is not
: guarranteed by the standard "invalidates" the code, so not
: assuming anything that is not guarranteed is neccessary to earn
: the attribute "valid", imho.
: From your last sentence I get the expression that you are talking
: about an implementation of the C language, not about "ANSI C code".
: If it is a confroming implementation, it will not break strictly
: conforming programs (This is how a conforming implementation
: is defined as far as I can remember).
I believe what he is talking about is a very interesting idea indeed: a
Conforming Implementation of Standard C, which deliberately implements
"implementation defined" items in totally unexpected (possibly widely
modifyable) ways, and really does blow up the universe when it sees
undefined behaviour. In other words, a test suite for ANSI/ISO C code.
There are such things to test actual compilers and libraries, but I have
never heard of one to test code. Anyone else?
--
+--------------------------------------------+
Martin Sohnius | "It doesn't matter whether the cat is |
Novell Labs Europe | black or white, as long as it catches |
Bracknell, England | mice." - Deng Xiaoping |
+44-1344-724031 +--------------------------------------------+
(I speak for myself, not for Novell or anyone else.)
|
| Sat, 01 Mar 1997 04:06:47 GMT |
|
|
|
Martin Sohni
#12 / 12
|
coding anti-anti-standards [was: coding anti-standards]
: > : >I believe what he is talking about is a very interesting idea indeed: a : >Conforming Implementation of Standard C, which deliberately implements : >"implementation defined" items in totally unexpected (possibly widely : >modifyable) ways, and really does blow up the universe when it sees : >undefined behaviour. In other words, a test suite for ANSI/ISO C code. : Yea, a long day and a late night when I wrote that...
: But that's excatly what I had in mind. Some tools like Purify help
: with certain aspects of this, but that's not really their intent. It
: would be interesting to go through the standard and count the number of
: things that are "undefined" or "implementation defined" and then
: implement such things in a really strange way.
| >: Are you really interested [... in C conformance checkers...]?
| >
| >Only in principle.
|
| OK. Well in principal, there is a fellow in England who makes a ``conformance
| checker'' for C programs. It checks many many aspects of a program (including,
| I think, some aspects of its run-time behavior) to insure that it is really
| a strictly standard conforming C program.
.. but he didn't know details, and since I was only interested "in principle",
I didn't wanna bother him. Just thought I'd let you know.
--
+--------------------------------------------+
Martin Sohnius | "It doesn't matter whether the cat is |
Novell Labs Europe | black or white, as long as it catches |
Bracknell, England | mice." - Deng Xiaoping |
+44-1344-724031 +--------------------------------------------+
(I speak for myself, not for Novell or anyone else.)
|
| Wed, 12 Mar 1997 04:43:07 GMT |
|
| |
