No UNSIGNED_BYTE in Any

[Lionel Elie Mamane]

On Thu, Jan 03, 2013 at 02:54:32PM +0100, Lubos Lunak wrote:
> On Thursday 27 of December 2012, Lionel Elie Mamane wrote:

>> The following code does not do what one would think:

>>  sal_uInt8 nValue = 255;
>>  Any aValue;
>>  aValue <<= nValue;

>> aValue now contains a *BOOLEAN*. That's rather... surprising, and
>> could bite any of us one day.

>  Why could? There's exactly the same problem with sal_Unicode and
> I'm pretty sure there already have been trouble with this.

For sal_Bool, it is worse, because it is normalised to sal_True or
sal_False. Which makes sense when one thinks of it as a boolean, but
when treating it as a sal_uInt8, it breaks the principle of least
surprise. If you do:

 sal_uInt8 nValue = 255;
 Any aValue;
 aValue <<= nValue;
 sal_uInt8 nValue2;
 aValue >>= nValue2;

then nValue2 contains 1, not 255. That's just devilish in my eyes.

By contrast, for FOO being *any* value (assuming sal_Unicode is sal_uInt16?):

 sal_uInt16 nValue = FOO;
 Any aValue;
 aValue <<= nValue;
 sal_uInt16 nValue2;
 aValue >>= nValue2;
 assert(nValue == nValue2); // assertion will *always* succeed

>> Since we are in our "unstable API/ABI" period, *if* we can have a
>> clean solution, let's have it for LibreOffice 4.1. Since the in-memory
>> layout of sal_Bool does not change (right?), this might even be fully
>> ABI-compatible? (but not API-compatible for C, but API-compatible for
>> C++)

>  Turning sal_Bool into a non-integer type breaks enough code to not
> be worth it (I know, I tried it once). If we decide to break ABI, we
> can just go with bool. If not, we probably can't do anything.

I was under the impression that my struct hack would not break ABI,
unless there are subtle issues I don't see (e.g. different alignment
rules)?

>> Why did I get into this? Well, see https://gerrit.libreoffice.org/#/c/1164/

> Unless you have _very_ good reasons, just don't bother with 8-bit
> integers.

Well, I'm faced with interfacing with systems that (potentially)
provide data with some 8-bit integers in them, and "as faithfully as
possible" present them to our users... Looks like I'll have to make an
exception for unsigned 8 bit integer in some way. This is very
annoying to me, because my longer-term intention was to offer an API like:

Any XRow::getAny(integer colNum)
Any XUpdatableRow::setAny(integer colNum)

To make code like this work:

 RecordSet src;
 RecordSet dst;

 for (i=1; i<=colCount, ++i)
     dst.setAny(i, src.getAny(i))

So, now, if column "2" contains an unsigned 8 bit integer... I can't
put a sal_Bool in the Any returned by src.getAny(2); so I introduce my
own UNO "struct" just to "wrap" 8-bit unsigned integer? I put a 16 bit
integer in it?  Introduce my own database-specific Any-like type
(basically exporting connectivity::ORowSetValue)? I'll have to think
about it...

-- 
Lionel