Suggestions

[Jonathan Coxhead]

 | 1. In DefMod, ensure that .Bool translates to osbool

   Yep.

 | 2. In types.h: 
 | 
 | typedef int osbool;
 | 
 | #if !defined( __GNUG__ ) && !defined( BOOL_DEFINED ) 
 |   typedef osbool bool;
 | #endif

   There are 2 "natural laws" we should attempt to respect:

      ---if |__cplusplus| is defined, |bool| is a keyword, and we
      shouldn't touch it or rely on it anywhere.

      ---in C99, |bool| is defined in <stdbool.h>, and we should
      allow library users to use that, or not, as they see fit. In
      practical terms, this means we shouldn't touch it or rely on it
      anywhere in this case as well. There are no C99 compilers for
      RISC O S (or anything) else yet, so we can make this change
      safely.

   In other cases, we should do what we do now, to be compatible.

 | G++ loses backward compatibility, but as it's a bug, it has to be
 | fixed. Any attempt at compilation using bool instead of osbool will
 | throw an error, so the user is aware of it. Obviously, old code 
using
 | the library, and compiled with G++ will need to be re-compiled, 
but I
 | guess there's not much we can do about that at this stage.

   Sounds good.

 | Any future limitation on the use of a 4-byte bool can be taken 
care of
 | by by the user defining BOOL_DEFINED, and using osbool.

   I don't see what problem |BOOL_DEFINED| is solving. Is this for 
non-C++, non-C99 systems that define |bool| themselves? Are there any?

 | Any objections so far? ;-)

   Nope.

 | Next, what to do with |TRUE| and |FALSE|? Apart from casting them 
to
 | |osbool| instead of |bool|, I'd be inclined to leave them alone; 
there
 | doesn't seem much point in changing them.

   Yes, you're right.

 | Next, should we change, as Jonathan suggested, |bits| and |byte| 
for
 | consistency? Again I'd be inclined to leave them alone; they are
 | oslib- specific anyway, and presently don't present a problem.

   Can't argue with that.

        /|
 o o o (_|/
        /|
       (_/