[sldev] BOOL patch, and test results.

[Andrew Meadows]

Callum Lerwick wrote:
> On Wed, 2007-05-16 at 21:30 -0400, Alan Grimes wrote:
>>>> Note 3: All instances of BOOL should be replaced with bool in all
>>>> functions, methods, and global data objects without hesitation or delay.
> 
>> Changes:
>>
>> - TRUE and FALSE have been removed and replaced with true and false as
>> per "The C++ Programming Language" by Bjarne Stroustrup
>>
>> - Many usages of BOOL have been removed. (About half the work remains)
>>
>> - Duplicate code has been removed, there were at least two instances of
>> trivial methods being implemented once for bool and again for BOOL.
>>
>> - Declaration/implementation conflicts have been fixed. The compiler was
>> accepting conflicts between S32 declarations and BOOL implementations
>> because they were the same type. These have been fixed in this release.
> 
> I would like to know what happens if you just typedef BOOL to an S8. Are
> BOOLs used in structures or arrays anywhere? It might reduce RAM usage
> but at the same time could throw off alignment as well.


The original reason for the BOOL typedef was to enforce known
byte footprints for all types.  The size of a bool is platform
dependent and we didn't want to get bitten between operating
systems when trying to pack bool's into packets and other binary
blobs.

BOOL probably should have been typedefed to an S8, but it was
set to an S32 instead.  Back then we were coding very quickly
and didn't care too much about losing a few bytes to the small
number of BOOL's we were using.

I think there are a few LL developers who are still attached to
BOOL's, not because they love wasting 31 or 23 bits per, I suspect
it is because they think the pain and suffering from mysterious
and intermittent bugs would outweigh the gains from minor
improvements in memory footprint or slightly prettier code.

You could probably safely replace most BOOL's with bool's, however
you'd want to be careful around any places where BOOL's
are fed to the LLMessageSystem, or stuffed into some other binary
bucket.  Just changing the typedef could cause interesting things
to happen.

Any comprehensive BOOL-->bool replacement would produce a patch
of such a magnitude that would generate a large number of merge
conflicts throughout the myriad of branches we're juggling internally,
and the conflicts would smolder over several weeks, or even months.
I don't know of any LL developer who would want to push such a
monster through the system, with little to show for it but
some slightly prettier code.  I think a more likely campaign
for change  would be for the sldev crowd to push
the LL devs to reach a consensus on a change to the coding
standard, and then start a gradual transition to bools -- all
new code should use bool's and old code is converted file by
file, in little deliverable chunks.

How could the sldev community apply pressure to LL?  One
idea is that the sldev community could simply make it
their policy to always use bools in any new code, and to
surreptitiously replace a few BOOL's in each patch.
When the bool's outnumber the BOOL's in most of the code
then I suspect you'll start to see various LL developers
follow suit and start opportunistically ripping out BOOL's
when they see them.  No recently hired LL developer is going to
like BOOL's, and a fair number of the rest of us are peeved by
the atrocity.

- Andrew