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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
