BOOL in Systypes.h

[Tony van der Hoff]

On 24 Dec, in message <843bc8654c.root at hop2.xs4all.nl>, you wrote:

Aren't you the guy who a few weeks ago had nothing good to say about OSLib,
its maintainers, the mail list, and my examples, resulting in my plonking
you? Well, glad to see you have decided to join us :-)

> Spoke too soon.
> 
yes...

[snip]
> oslib/types.h does not define BOOL. It defines BOOL_DEFINED, and if needed
> does a
> 
> typedef osbool bool;
> 
Yes, the history of the usage of bool/BOOL in OSLib is a long and
complicated one, and as you may see from the ChangeLog has changed several
times, mainly to accommodate the differences between various compilers and C
standards as they evolved.

The current solution is the culmination of significant effort of people who
are highly versed in the complexity if the C standards, and they and I
believe it works fine.

OSLib does not define BOOL (the constant) anywhere. As you have observed,
macros.h *does* define BOOL(c) as a macro. This is perfectly acceptable;
they may co-exist with the constant without ambiguity.

[snip]
> 
> #define BOOL(c) ((c) != 0? TRUE: FALSE) ========================
> 
> This conflicts with Systypes.h *and* is unneccesary. Instead of the
> BOOL(x) the programmer can simply write (!!x) or (TRUE && x), and the
> compiler will convert from zero/nonzero to zero/-1.
> 
Neither of your assertions is correct. No conflict, and the question of
whether or not *you* find it unnecessary is not under discussion. In fact
the construct is used within the toolchain source, and therefore *is*
necessary. I'm certainly not going to remove it and cause people who do use
it compatibility problems.

> So the chain goes like this: In the !Dustbin example, main.h uses BOOL.
> BOOL is #defined in Systypes.h as bool. oslib/types.h ensures bool is
> typedef-ed. (In my Norcroft C99 compiler, bool is typedef-ed in
> C:stdbool.h).
> 
All correct. The definition of bool in types.h is subject to a number of
tests, one of which is for a C99 compiler. There is no problem here.

> My remaining gripe is now with oslib/macros.h. The macro def there
> prevents a succesful compilation of the !Dustbin example.
> 
I believe you've misunderstood the precompiler syntax. It's *not* preventing
compilation. You could have proved this to yourself by commenting out the
line which you found offensive in macros.h.

The *real* problem is this: OSLib correctly detects that you are using the
C99 compiler, and expects #include stdbool.h in the source code. This was
not present, because it did not exist back in '96. So, the first move is to
#include it in h.main.

Fixing this shows up a couple of errors in the application; in c.MainWnd
EmptyProc() should return osbool, not bool; and similarly for c.Main
IconMenuQuitProc().

Finally, to avoid link errors, the application should be linked with OSLib32
and OSLibSupport32. Having done this, the application builds and runs
correctly with the Castle tools, and the 32-bit library.

As you see, whilst there was a problem, your diagnosis of it was way out. I
respectfully suggest that maybe in future, until you gain a bit more
experience of debugging C programs, when you see a problem like this, you
post the symptoms of the problem rather than jumping to conclusions, as you
previously did in your newsgroup posting and in this list. It would make
helping you a more pleasant task. Do please remember that we are all
volunteers, giving our time freely, to help the community. Your contribution
is greatly appreciated.

Thanks, anyway for highlighting a problem with the examle application; I
shall upload a fixed version to the website forthwith.

-- 
Tony van der Hoff
Buckinghamshire England