HDTenEightyP/NetNews huggingface dataset:
From: martelli@cadlab.sublink.org (Alex Martelli)
Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.pascal,comp.lang.misc
Subject: Re: Software design =/= Programming
Date: 4 Nov 92 07:32:18 GMT
Organization: CAD.LAB S.p.A., Bologna, Italia

mollers.pad@sni.de (Josef Moellers) writes:
	...
:Although I have had some contact with good ole Goedel (I've done a
:course in theoretical CS, I've read the book (Hofstadter), I've seen the
:film (sorry, got carried away)), I always wondered what this
:"unprovable" was all about.
:When I was at school, I was taught that there existed things like
:- axioms
:- theorems
:- lemmata
:where "axioms" were the foundation of the whole, things that have to be
:taken for granted, that cannot be proven, that "just are".
:If You change one or more of Your axioms, You can arrive at a completely
:different set of statements, sometimes interesting ones, sometimes wierd
:ones. Nevertheless, "axioms" are nothing special.
:Now comes Mr. Goedel and sais that there exist, in mathematical theory,
:things that cannot be proven. Then I say "OK, these are axioms, so
:what?" "Axioms", to me, are the very atoms (from greek "unseperable")
:that make up "maths". Every now and then someone comeas along and shows
:that one of these "atoms" can indeed be broken up, i.e. one of the
:"axioms" is a consequence of other axioms, therefore can be proven.

The point of Goedel's Theorem is, that for *ANY* formal system "powerful
enough" (arithmetic on numbers, and anything able to include it, ARE
powerful enough in this sense), *ANY* set of axioms which do not lead to
contradiction (=>being able to prove both A and NOT A for some A, thus,
by formal logic, being able to prove ANYthing whatsoever!), IS incomplete:
there will be *true* statements about the formal systems that cannot be
proven from that set of axioms!!!  It does little good to say, "oh well
then, I shall add those true statements as new axioms", because the new
axiom set that you thus obtain will STILL be incomplete - there will be
OTHER true statements which can't be proven in the system, and so on, AD
INFINITUM.  Adding an infinity of axioms at once is no better - unless you
introduce contradiction, there WILL still be true statements that cannot
be proven!!!
-- 
Email: martelli@cadlab.sublink.org                   Phone: ++39 (51) 6130360
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: ++39 (51) 6130294 
Newsgroups: comp.lang.c
From: ae007@yfn.ysu.edu (Daniel Newcombe)
Subject: Please help me with my #include mess-up.
Organization: Youngstown State University/Youngstown Free-Net
Date: Wed, 11 Nov 1992 17:28:40 GMT


Well here is my problem:  I have these modules:
  MOSTYPES.H - defines several types I am using in this
    project, such as boolean, and a few structs and typedefs
QUEUE.H - the header file for my queue class which has a few
   inline things in it.
   This has to include mostypes.h because it needs boolean.
QUEUE.CPP - the rest of the code for the queues.  It includes
  queue.h
MAINMOD.CPP - my main module.  It includes QUEUE.H and MOSTYPES.H.
When I compile I get a whole mess of errors saying that all sorts
of things in MOSTYPES.H are redefined.  There are a lot more        
modules that are going to have to use mostypes.h before it's   
all over with.

My question - how do I get this to compile, while still keeping
the code portable and re-usable???

thanks...  -Dan
-- 
    -Dan Newcombe
Internet Address:  STDN@VM.MARIST.EDU
Youngstown Freenet: ae007@yfn.ysu.edu
GOAL: To put the world on 3.5" diskettes...  :)
From: Frank_E_Stock@cup.portal.com
Newsgroups: comp.lang.c
Subject: RE: THINK C problem
Date: Fri,  6 Nov 92 19:38:50 PDT
Organization: The Portal System (TM)

Geoff,

I am not sure I fully understand your problem.  I need more info.  However
a bit of trivia for you, THINK C will not allow you to mix stdio call with
Macintosh toolbox calls in the same program.  I know its pretty lame.  If you
must do this in C and need both types of calls, MPW will do it in a SIOW type
environment.

Hope it helps
Frank Stock
From: anb@doc.ic.ac.uk (A N Burton)
Newsgroups: comp.lang.c
Subject: Re: How to print an integer as binary?
Date: 6 Nov 1992 14:34:21 GMT
Organization: Department of Computing, Imperial College, University of London, UK.
Distribution: world
NNTP-Posting-Host: mfast.doc.ic.ac.uk


Many thanks to those who pointed out errors etc in my code.

What I hope are more correct versions of the functions appear below.

Ariel BURTON




#include	<stdio.h>
#include	<limits.h>


void
aux1( long x ){
	if( x ){
		aux1( x / 2 );
		putchar( (x%2) ? '1' : '0' );
	}
}

void
PrintBinary1( long x ){
	if( 0 == x )
		putchar( '0' );
	else{
		if ( x < 0 )
			putchar( '-' );
		else
			x = -x;
		aux1( x );
	}
}
#define MAX_SIZE ( CHAR_BIT * sizeof( long ) )
void
PrintBinary2( long x ){
	char	buff[ MAX_SIZE+1 ];
	int	i;

	if( ! x )
		putchar( '0' );
	else{
		if( x < 0 )
			putchar( '-' );
		else
			x = -x ;

		buff[ i = MAX_SIZE ] = '\0';
		for( ; x ; x /= 2 )
			buff[ --i ] = (x%2) ? '1' : '0';

		printf( "%s", buff+i );
	}
}

void
PrintBinary3( long x ){
	unsigned long	mask = (((unsigned long)(-1)) >> 1 ) + 1;

	if( ! x )
		putchar( '0' );
	else{
		if( x < 0 ){
			putchar( '-' );
			x = -x;
		}

		for( ;  ! (x & mask) ; mask >>= 1 )
			;

		for( ; mask ; mask >>= 1 )
			putchar( x & mask ? '1' : '0' );
	}
}

main( int argc, char *argv[] ){
	PrintBinary1( atol(argv[1] ) );
	putchar( '\n' );
	PrintBinary2( atol(argv[1] ) );
	putchar( '\n' );
	PrintBinary3( atol(argv[1] ) );
	putchar( '\n' );
}
Xref: sparky comp.lang.c:16054 comp.lang.c++:15847 comp.lang.pascal:6364 comp.lang.misc:3512
From: faustus@ygdrasil.CS.Berkeley.EDU (Wayne A. Christopher)
Newsgroups: comp.lang.c,comp.lang.c++,comp.lang.pascal,comp.lang.misc
Subject: Re: Software design =/= Programming
Date: 6 Nov 1992 05:14:05 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: ygdrasil.cs.berkeley.edu

In article <1992Nov04.073218.11970@cadlab.sublink.org> martelli@cadlab.sublink.org (Alex Martelli) writes:
> The point of Goedel's Theorem is, that for *ANY* formal system "powerful
> enough" ... there will be *true* statements about the formal
> systems that cannot be proven from that set of axioms!!!

Not exactly -- what it says is that for any set of axioms A there will
be statements S such that A does not imply S and A does not imply not
S.  The notion of truth doesn't come into it, since in a formal system
either something is provable or isn't.

	Wayne
Newsgroups: comp.lang.c
From: glanton@sctc.com (John Glanton)
Subject: TC 2.0: unable to open include files
Organization: SCTC
Date: Mon, 9 Nov 1992 23:06:52 GMT

Has anyone run into this error.  I only get it with nested includes
in \tc\include.  The files exist and are where one would expect them
to be but TC can't open them.  For example, when including stdio.h
I get this error when TC tries to open stdarg.h.

Thanks in advance

-- 
                John F. Glanton        glanton@sctc.com
----------------------------------------------------------------------
     If you thought the L.A. riots were bad ... watch minneapolis
                    if the twins don't sign Kirby
From: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Newsgroups: comp.lang.c
Subject: Auto. conversion of function arguments
Date: 9 Nov 92 13:06:40 GMT
Reply-To: jim@jagubox.gsfc.nasa.gov (Jim Jagielski)
Organization: NASA/Goddard Space Flight Center

I know that it's bad programming practise, but is the following "legal"?

Assume you have a function that accepts a char parameter. Now we know
that whenever an integral argument is passed by a function call, chars
and shorts are promoted to int...

Sooo... assuming you call a function that accepts 'char', is there any
_real_ reason why you must cast shorts and ints to char in the function
call itself? After all, the parameter always "arrives" at the function
as an int, so it "appears" that another automatic conversion takes place:
from the int that arrives to the type of the parameter (assuming that they
are both of integral or floating types... I'm not talking about going from
int to float or whatever)...

True enuff (even if it _is_ bad practise)?
-- 
    Jim Jagielski               | "It is not I who am crazy...
    jim@jagubox.gsfc.nasa.gov   |  it is I who am MAD!"
    NASA/GSFC, Code 734.4       |
    Greenbelt, MD 20771         |            - Ren
Newsgroups: comp.lang.c
From: jbs@rti.rti.org
Subject: Need CURSES test battery
Organization: Research Triangle Institute, RTP, NC
Date: Thu, 5 Nov 92 21:19:05 GMT

We have hacked up a curses library for a 386 compiler, but don't have
the source for any software that uses curses really heavily to give it a
thorough testing.
Any ideas for something that would fit the bill?  I'd like to stay away
from programs that use a lot of system-specific routines.

Thanks in advance.

  -joe

jbs@rti.rti.org
From: sasghm@theseus.unx.sas.com (Gary Merrill)
Newsgroups: comp.lang.c
Subject: Re: Fortran to C conversion: Why bother?
Date: 11 Nov 92 16:32:11 GMT
Article-I.D.: unx.BxK8Ln.Hw9
Organization: SAS Institute Inc.
Originator: sasghm@theseus.unx.sas.com


In article <1992Nov11.150325.27062@nntp.nta.no>, hlj@hal.nta.no (Harald Ljoen FBA) writes:
|> 
|> In article <1992Nov9.131601.167@gems.vcu.edu>, hleaves@gems.vcu.edu writes:
|> >I was wondering why anyone would bother using the f2c (or similar) program to
|> >translate fortran code directly into C. All you end up with is C code that
|> >exactly mimics the functionality of the original fortran code. Its not as if
|> >the translating program rewrites your algorithms to use the parts of C that
|> >make C really useful. Its just fortran code expressed in C. What's the point?
|> >If you're going to write programs in fortran, use a fortran compiler. If you
|> >want to use the features of C, learn C and use a C compiler. Using f2c doesnt
|> >give you any of the advantages of designing and writing the original program in
|> >C.
|> 
|> If we could click on a button with the label "undo-and-redo-in-C-the-last-35-
|> years-work-of-one-zillion-scientists" the above would make sense.
|> 
|> f2c is used by C programmers that want to utilize existing, well-proven and
|> available code written in FORTRAN. Why reinvent old wheels?
|> 
|> -- 
|> ** Also sprach harald.ljoeen@nta.no **

One problem is that the well-proven-ness property is not preserved
under translation.  Other properties not preserved are:  readability,
extensibility, and efficiency.
-- 
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
From: potts@oit.itd.umich.edu (Paul Potts)
Newsgroups: comp.lang.c
Subject: Re: Godel's Proof (was Re: Software design =/= Programming)
Date: 11 Nov 1992 20:41:10 GMT
Organization: Instructional Technology Laboratory, University of Michigan
NNTP-Posting-Host: helen.oit.itd.umich.edu

In article <4002@eastman.UUCP> vec@alnitak.Kodak.COM (Vance Cochrane) writes:
>
>WHAT DOES THIS HAVE TO DO WITH THE C PROGRAMMING LANGUAGE !!!!!
>ANSWER:
>NOTHING.

What does the C Programming Language have to do with this newsgroup?

-- 
"What good is a computerized nose?" - Lou Reed - potts@oit.itd.umich.edu
From: jamshid@ut-emx.uucp (Jamshid Afshar)
Newsgroups: comp.lang.c
Subject: Re: Typedefing builtin... thanks.
Date: 12 Nov 92 22:13:10 GMT
Reply-To: jamshid@emx.utexas.edu
Organization: The University of Texas at Austin; Austin, Texas

In article <1992Nov9.150414.10221@odin.diku.dk> jkut@diku.dk (Jonatan Kutchinsky) writes:
>People generally tended to agree with me on the use of the names BYTE, WORD,
>and LWORD to represent unsigned 8, 16, and 32 bit variables in my simulation
>of a Motorola 68000 processor. Some even proposed the use of special 
>functions or macros for calculations, conversions to builtin types, and for
>I/O. We are going to use this in our computer science project.

I agree, but remember these typedefs are only appropriate because that
is what your application is modeling.  It would use these typedefs as
another app would use HostID or SocialSecurityNumber.  The rest of
your code should use int, long, etc.  I agree it would be a good idea
to use functions/macros for performing the 68000 arithmetic operations
instead of just writing
	WORD r1, w1, w2;
	/*...*/
        r1 = w1 * w2;
especially since multiplication in the processor might result in a
LWORD (?), while in C the result is the same type as the operands.

>One stated that in his ideal program, builtin types were never used, and
>names like f.x. Counter, and BigCounter would represent int and perhaps long,
>depending on the machine used.

I don't agree with this at all.  That extra level of abstraction adds
nothing and introduces its own complications (eg, what type specifier
do you use for printf()?).

>The major arguments used to justify these techniques were about portability.
>A program is easier to port, when you can change some typedefs in a header
>file, instead of changing a lot of ints to longs all over the code.

I see your BYTE, WORD typedefs as increasing readability and providing
data abstraction, which eases porting.

In general you should not have to change your code from using 'int' to
using 'long'.  Use 'long' if the value might be larger than 16-bits,
otherwise just use 'int'.  Often you can use 'size_t'.

Jamshid Afshar
jamshid@emx.utexas.edu
From: mikey@ontek.com (euphausia superba)
Newsgroups: comp.lang.c
Subject: Re: The Correct Way To Write C if-Statements
Date: 9 Nov 92 19:13:08 GMT
Followup-To: alt.dev.null
Organization: Ontek Corporation -- Laguna Hills, California

I was hoping that I could sit idly by while someone else posted my
opinion about code formatting so that I could appear aloof to this
tired old subject.  Alas, no one (at least not this time around) 
has brought up this viewpoint:

Establishing a consistent, company-wide style of code formatting
results in a loss of information.  When several programmers
collaborate on a project, even a source code control system has
difficulty identifying exactly who wrote what statement.  Each
programmer should be free to establish his own style, to serve as a
signature so that in case of a question about the code later, there
is at least some *hint* as to who exactly screwed up, without having
to check out old revisions and compare the modifications (if they
are even available.)

So that nobody is tempted to follow this up with the flaws
in my reasoning, I'll mention them here:

1. There are only so many cohesive "styles" available to
   choose from.  After hiring, say, 20 programmers, it's
   almost a certainty that a several will have styles so
   close as to be indistinguishable.

2. Programmers can "disown" code they're ashamed of by rewriting
   it in someone else's style. 

3. Some anal-retents, when given a hunk of code to maintain
   or enhance, will reformat it before beginning work on
   on it anyway, erasing the style-signatures of the previous
   authors and wasting time in the process.

4. The main thesis of advocates of enforced coding styles: that 
   these differing styles lead to unreadable code.

But a little "Hey, Bob, did you write this?  Can you tell me if..." 
from time to time is a surprisingly effective productivity tool and
should not be discarded in the name of readability.

This is a subject that's been posted to death several times over the
years, and there's about a 50-50 chance I'll end up cancelling this
message anyway.  Followups to alt.dev.null.

      the krill
From: mcsbc2gw@dct.ac.uk
Newsgroups: comp.lang.c
Subject: Re: c source code printer
Date: 6 Nov 92 10:58:12 GMT
Organization: Dundee Institute of Technology

In article <1992Nov2.202041.22753@magnus.acs.ohio-state.edu>, esova@magnus.acs.ohio-state.edu (Edward R Sova) writes:
> 
> Where may I ftp a program that will print my C-source code, in a more organized
> way for DOS?  Pagenation, line numbering, date/time stamps, headers and such?

	I remember seeing a C beautifier somewhere before, since its' p.d.
	it should be widley available

> Thanx,
>   ___
>   \  \      Mr. Ed on rollerblades?  Nah, that's:
>   _\  \      esova@magnus.acs.ohio-state.edu       Prodigy:CBGX09A
>  \_____\       but his friends call him Ed,
>  o o o o                    yeah that Ed Sova Kid, he answers to anything.
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: How to use 'return' in c?
Organization: Texas Instruments Inc
Date: Mon, 9 Nov 1992 19:08:38 GMT

In <gm5XTB3w165w@quest.UUCP> kdq@quest.UUCP (Kevin D. Quitt) writes:

>darcy@druid.uucp (D'Arcy J.M. Cain) writes:

>> allebrandi@ipact.com writes:
>> >The best thing to do is to use manifest constants to implicitly document
>> >the value you are returning. For example, return TRUE or FALSE not 1 or
>> >0 for a boolean function return.
>> 
>> Whenever I see TRUE and FALSE in code I am maintaining I remove the
>> #defines.  If they are defined, they should never be anything but
>> TRUE = 1 and FALSE = 0.  Anything else is confusing and misleading.

>    On the other hand, since C does not truly support the boolean type,
>I consider it misleading to assign a numeric value to a boolean.  I
>define TRUE as (1==1) because the result of this is a boolean - the
>fact that it is represented by a numerical value is misleading.

No, the result of this is *1*.  If it is anything else, your compiler
is seriously broken.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.c
From: giglio@betsy.gsfc.nasa.gov (Louis Giglio)
Subject: EBCDIC to ASCII Conversion
Reply-To: giglio@betsy.gsfc.nasa.gov (Louis Giglio)
Organization: NASA/GSFC
Date: Thu, 5 Nov 1992 17:22:40 GMT

Does anyone know of a good way to convert EBCDIC characters to ASCII?
I have the unfortunate need to transfer binary files from an IBM mainframe
to our UNIX machines.

Thanks.


Louis Giglio
Severe Storms Branch
NASA/GSFC
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: The Correct Way To Write C if-Statements
Date: 12 Nov 92 10:16:54 GMT
Article-I.D.: thunder.1992Nov12.101654.21932
Organization: McGill Research Centre for Intelligent Machines

In article <2184@ontek.com>, mikey@ontek.com (euphausia superba) writes:

> Establishing a consistent, company-wide style of code formatting
> results in a loss of information.  [...]

> 3. Some anal-retents, when given a hunk of code to maintain or
>    enhance, will reformat it before beginning work on on it anyway,
>    erasing the style-signatures of the previous authors and wasting
>    time in the process.

As onje of the group you slur as "anal-retents" here, I'd like to point
out that perhaps there's a *reason* for this action, beyond just
looking to make trouble, beyond even the aesthetics of mixing code
styles.  In my case, the reason I reformat code is usually that the
existing brace placement is such as to cause the C-mode I use to place
my code with its left margin off around column 60 or so.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: tbruseha@hollywood.ems.cdc.com (Tom Brusehaver)
Newsgroups: comp.lang.c
Subject: Malloc Debug
Summary: malloc debug
Keywords: debugging random free's
Date: 6 Nov 92 16:24:02 GMT
Organization: Empros Systems International, a division of Control Data

I am porting some code, and I wish I could rewrite it, but I can't.  I
need a tool to to debug malloc on an RS/6000.  I know there are Sun
versions around (one is included in the pre-Solaris OS's).  I need an
RS/6000 tool that will catch errant pointers before they crash my
program.


Thanks

Tommy B.
From: J074870@LMSC5.IS.LMSC.LOCKHEED.COM
Subject: Re: NEED TO 'C'
Organization: Lockheed Missiles & Space Company, Inc.
Date: Wed, 4 Nov 92 20:38:06 GMT

------------------------- Original Article -------------------------
Xref: iscnvx comp.lang.c:34971 comp.lang.c++:26720 comp.misc:10342
From: fhi0055@hq.dla.mil (Marc Poole)
Newsgroups: comp.lang.c,comp.lang.c++,comp.misc
Subject: NEED TO 'C'
Date: 4 Nov 92 12:00:09 GMT
Followup-To: poster
Organization: HQ Defense Logistics Agency/DASC, Cameron Station, VA


 In a course study of the language turbo 'c', it was suggested that
 students should pick up a copy of THE C PROGRAMMING LANGUAGE 2ND
 EDITION - ANSI C, by Dennis Ritchie and Brian Kernigan.  Unfortunately
 throughout my search I am unable to find it anywhere.

 Can anybody tell me where this book can be ordered from or who might
 carry a copy?
---------------------------------------------------------
I don't know if you have a chain called "Software Etc." out there but
they usually carry it.  Also, most bookstore chains can order it for
you.
Matt Shember
From: psumnsky@bimacs.BITNET (Moshe Pasumansky)
Newsgroups: comp.lang.c
Subject: LEX and Borland C++ 3.1 incompatibility.
Date: 12 Nov 92 18:04:56 GMT
Organization: Math department, Bar-Ilan University, Ramat-Gan, ISRAEL

Subject: LEX and Borland C++ 3.1 incompatibility.

        Hi everybody !

  Since in my local host nobody was able to answer my question, I post it
here. I made my project using YACC and LEX for PC, and MSC 6.0. It worked
fine. But after some time I've decided to transfer it to Borland C Compiler,
since, unfortunately, most of PC C programmers prefer it (although I am sure,
that MicroSoft is best), and so it will be more easy to maintenance it by
the next generation of students...  After recompiling the sources I've got a
pile of warnings in the my "yylex.c" file, but I just didn't pay attention
to it, since MSC C also looked unhappy when it compiled it. But when I
tried to run the program, it produced something unreasonable... After some
debugging I've released that the problem is in the "yylex" function. I wrote
simple test in LEX, and it didn't work properly too. It seems, that the
problems are in the "yylook" subroutine, and they are caused from the
"Suspicious pointer conversion" warning. I.e., I think, that when it
tries to get values from the tables (offsets etc), it get them wrong. I even
tried to do some hacking on "ncform.c" LEX driver in order to fix it, but
unsuccessfully. (probably the code is too complicated for me).

  So, if anybody was faced with this problem, or even has alternative version
of LEX, please e-mail me. I use the fully undocumentated LEX and YACC,
and I even don't remember from where did I get them. The LEX seems to be
compiled by Microsoft compiler (the message "Microsoft Run-Time Library 1990"
in the code).

  Thank's in advance, hoping to receive responds,
        Mosha.

My InterNet address: psumnsky@bimacs.cs.biu.ac.il
Newsgroups: comp.lang.c
From: "hans friedrich steffani" <GM08@DKAUNI2.BITNET>
Subject: Re: How to use 'return' in c?
Organization: University of Karlsruhe, Germany
Date: Thu, 12 Nov 1992 09:42:24 GMT



> From: kdq@quest.UUCP (Kevin D. Quitt)
> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>
> > In <gm5XTB3w165w@quest.UUCP> kdq@quest.UUCP (Kevin D. Quitt) writes:
> > >    On the other hand, since C does not truly support the boolean type,
> > >I consider it misleading to assign a numeric value to a boolean.  I
> > >define TRUE as (1==1) because the result of this is a boolean - the
> > >fact that it is represented by a numerical value is misleading.
> >
> > No, the result of this is *1*.  If it is anything else, your compiler
> > is seriously broken.
>
>     No, the result is *represented* by a 1.  "1" is not a boolean value.
> TRUE is a boolean value that requires a numeric definition because of
> the limitations of the language.  Other languages have booleans and do
> not allow assigning numeric values to booleans.  (On the other hand,
> most of *those* languages are otherwise so broken as not warrant their
> use.)
there is no reason to worry abt #define TRUE 1 or #define TRUE 42,
if you do not use TRUE in a comparison. #define TRUE 0 is also
possible but sensless as the compiler handles TRUE as false.
(It is like #define THREE 24).
--
hans friedrich steffani
Newsgroups: comp.lang.c