Re: [Libreoffice] [PATCH] Add support for bool for the operator << and >> of SvStream

On Tue, 2010-10-05 at 11:33 +0100, Michael Meeks wrote:
> Hi there,
>
>       Fair enough; so an explicit cast in the code calling the operator:
>
>       rStrm << static_cast<sal_uInt8>(aBool) << ...;
>
>       sort of thing ?

Do we have a concrete example of where we have a BOOL getting streamed
out at the moment ? My first instinct would be to change whatever aBool
element is currently a BOOL and getting streamed to disk to a sal_uInt8
in its declaration. e.g.

struct StreamMe
{
    sal_uInt16 foo;
-    BOOL bar;
+    sal_uInt8 bar;
};

rather than getting into cast foo.

> > I see we also have a << >> SvStream operators for "long" which is
> > another disaster seeing as a long is either 32bits of 64bits in size
> > depending on platform.
>
>       Weelll ... the operator in fact only streams 4 bytes regardless of
> architecture ...

Well, has the bright side that at least anything streaming longs isn't
creating dumps which can't be read on a different long-sized arch.

>       I guess; OTOH - do we really want to get into some monster LONG ->
> sal_Int32 replacement scheme just now ? :-) I'd rather get hackers
> re-focused on the higher-win tasks further up the stack really.

Sure, its not critical, but 32bit vs 64bit long/sal_Int32 mixups cause
real bugs. e.g.
http://cgit.freedesktop.org/libreoffice/components/commit/?id=18e69aa675aed764226eb496a34a8c0313e9c9d0
which is a different area, but illustrates the kind of cockup which
might be hiding from us at the moment.

C.