[Libreoffice] [PATCH] harmonization of BOOL vs sal_Bool as a prep for BOOL to bool converstion

[Michael Meeks]

Hi Norbert,

On Mon, 2010-10-04 at 11:46 -0500, Norbert Thiebaud wrote:
> My goal is to push sal_Bool (i.e bool as unsigned char) as much as
> possible to the boundary.

	Its a great goal :-)

> But I'm not sure where that ABI boundary is.

	At the moment, replacing any BOOL -> bool will not cause grief; in a
blue-sky future doing a s/sal_Bool/bool/ -may- cause grief (though I'm
hopeful that even that will be ok).

>  Is there a document somewhere that explain what is the ABI (IOW
> what interfaces are 'ABI public' versus interface used only internally

	Well, above 'sal' - there is not much; UNO interfaces are generated and
thus hard to change to bool anyway, so - you won't have too many
problems I think.

> The way I am proceeding is to change
> typedef sal_Bool BOOL
> to
> typedef bool BOOL
>
> and then compile, find problems, fix them, then change back the typedef
> re-compile - to make sure that there are still no problem

	Sure - a good approach.

> and make a patch with the change so far
> Without the support of << >> fo bool, this is the first thing that
> break and I would have to re-patch them every time to move forward
> (and not forget to undo it before submitting a patch...
..
> Yes good point. I didn't realized then that sizeof(bool) is not
> specified by the C++ standard
> I can very easily keep the serializetion use sizeof(char).

	Ah ! fine, so lets just make sure that the bool code just does a cast
to unsigned_char and calls that operator - so the intention is clear :-)
- can prolly do that with an inline in the header.

> how about setting up a git repo on github or something, so that you
> can pull from that rather than post-processsing my emails ?

	Hmm - it would be a big old repo.

> > 	a) we don't touch any UNO-ised methods (yet[1]) [ these are
> > 	   generated with sal_Bool anyway ].
> 
> Again. How do I identify for sure what constitute a UNO-ised method ?

	It would have some com/sun/star/foo/StdlyCaps.hpp type header - and it
would be javaNamed();

> > 	c) you have checked a diff before/after of:
> > 		'make vtable_check'
> > 	   to ensure we didn't accidentally spike any virtual methods
> 
> What does vtable_check check (*)? How to interpret the result ?
> (*) yes it check the vtables... that much I figured out :-) but bear
> with me. I'm a C guy. My C++ experience is very superficial.

	Heh ;-) so - I have written a blog entry about the problem so hopefully
others can have fun too:

	http://people.gnome.org/~michael/blog/2010-10-04.html

	Hopefully this will be generally useful, not just for your
re-factoring, but for adding new features of all kinds.

	HTH,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot