Michael Meeks wrote:
On Thu, 2007-02-08 at 16:50 +0100, Stephan Bergmann wrote:
Michael Meeks wrote:
The rtl_string2UString direction (OString -> OUString) is not that
problematic, as usually there should not be translation problems.
So, yes, I made a complete contradicting fool of myself. ;) How about
the following then?
While often there are no translation problems in the OString -> OUString
direction, there nevertheless *can* be such problems, manifest in the
RTL_TEXTTOUNICODE_FLAGS_xxx_ERROR flags. What use are those flags if
you cannot tell whether an error occurred? That's where
rtl_string2UString and the OUString(OString) ctor are flawed (see e.g.
configmgr/qa/unit/performance.cxx:1.1.2.3 l. 84 for a consequence of
that flaw). I'd wish that new API was not designed flawed from the start.
Ah; so - I'm just scared that adding this adds a not very useful
feature to almost every call, we bloat the code, add a load of branches
to a hot path and not much that is useful :-) Also, 'intern' is an
optimisation - people presumably don't use it for hard-core string
conversion.
Anyhow, I split the body of rtl_string2UString out to avoid duplicating
code and added a pInfo param. Since there is (apparently) no in-line
documentation for rtl_convertTextToUnicode, my param docs are brief.
Committed some changes to make the code compile werror-clean on unxlngi6
and unxsoli4 (this got rid again of SAL_INTERLOCK_BITS---I hope you
don't mind).
I am not happy with the changes to ustring.c: sal_uInt32 * pInfo,
though poorly of under-specific type, should only transport
RTL_TEXTTOUNICODE_INFO_xxx flags (which have well-defined semantics, see
<http://udk.openoffice.org/cpp/man/spec/textconversion.html>).
Apparently, rtl_string2UString traditionally ignored out-of-memory
conditions and returned nonsense---what a broken mess. However,
misusing pInfo to transport the wrongly-typed
RTL_TEXTTOUNICODE_FLAGS_UNDEFINED_ERROR to signal out-of-error
conditions strikes me as odd. (IMO, ideally, at the C++ level, intern
would throw std::bad_alloc for out-of-memory conditions and indicate
conversion problems via the sal_uInt32 * pInfo, or by throwing another
type of exception. Admittedly hard to get that into the sal/rtl mess.)
Fixed & I hope this means you will buy me a beer if in 5 years time,
no-one, anywhere has used this API feature ? :-)
No need to wait that long, you can have the beer straight away. (A
gallon if you also sign the configmgr-maintenance-master contract, btw.) ;)
On a slightly different topic: When done, please remember to post the
new API also to [EMAIL PROTECTED] (in case you had not been aware
of it).
-Stephan
Regards,
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
