[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: casts

From: Klaus Weide
Subject: Re: lynx-dev Re: casts
Date: Tue, 19 Oct 1999 20:31:03 -0500 (CDT)

On Tue, 19 Oct 1999, Webmaster Jim wrote:
> On Tue, Oct 19, 1999 at 09:12:16AM -0500, Klaus Weide wrote:
> > I wish you could have "just ignored the messages" from that Borland
> > compiler, or found a switch to turn them off...
> Sorry, I sometimes assume compiler authors know more than I do :-)

Did you tell it that you are really compiling C and not C++? :)

> > There doesn't seem a point to most of those warnings you are trying
> > to suppress.  Or if there is, then maybe it should be fixed in the
> > header files (e.g., what is BOOL?).
> I'd certainly agree to fixing the source of the warnings in a more
> logical fashion.  "BOOL" is short for BOOLEAN; why have both?
> Why not just use TRUE/FALSE? I have no idea...

It's historical, as far as I have been able to figure out.

The WWW Library uses BOOL / YES / NO for its variables and functions.
The Lynx application code uses BOOLEAN / TRUE / FALSE for its variables
and functions.

I find it is actually a useful distinction.  When you see a BOOL in
the src part, it's a hint that the variables may have something to do
with the lower layers.  When you see a BOLEAN in the Library part,
it's a hint that it was added for Lynx and has something to do with
the closer-to-the-user layers.  Of course it has all got a it mixed
up in the course of time.

> This could be wiped out of HTUtils.h, leaving just BOOLEAN:
> #ifndef BOOL
> #define BOOL BOOLEAN
> #endif
> Or just use char, which is what BOOLEAN is typdef'd to.

If anything, I would prefer to get rid of BOOLEAN and keep using
BOOL, to make integrating code from the newer libwww not more difficult
that in already is.  But I see no point in such a cleanup anyway.

Does the defien above actually apply?  It wouldn't if your compiler
predefines a BOOL symbol.

Anyway, normally BOOL and BOOLEAN are the same; I don't think the
difference has something to do with the warnings you got.
Try #defining BOOL (and BOOLEAN?) to be 'int', or, if your compiler
has such types, 'bool' or 'boolean'.  That would probably get rid
of the warnings without cast, but lynx would use slightly more memory
(at least for 'int').


reply via email to

[Prev in Thread] Current Thread [Next in Thread]