Obsoleting RTL_CONSTASCII_USTRINGPARAM

[Lubos Lunak]

On Thursday 09 of February 2012, Caolán McNamara wrote:
> On Thu, 2012-02-09 at 18:16 +0100, Lubos Lunak wrote:
> > suggests that OString in fact does not stop at \0's when handling
> > strings. I'm kind of baffled by this, I personally consider it a flaw
> > that a string class does this, but the unittest is very explicit about
> > this. Does somebody know?
>
> svtools/source/svrtf/parrtf.cxx:345 is a in-action example. Where rtf
> can describe a character in hex bytes and for list strings '00 to '09
> are used as placeholders for the list level to substitute into the
> string, or something like that. Vaguely recall there might be similar
> stuff in some of the binary ms file formats, where their strings tend to
> be pascal-style length-prefixed strings and while embedded nulls aren't
> common they might arise a bit. Anyway, as it stands embedded NULLS are
> legal in O[U]Strings

 I think using something like vector here would be a better choice (or rather 
not a bad choice), but ok, then I can either move the check to the new ctor 
or assume that the const char[][N] case is so unlikely to happen that it's 
not worth checking for explicitly. I guess I'll just go with the latter.

> > So while I can be talked into adding the explicit, I can't find any
> > good reason for doing that.
>
> core/sal/textenc/textenc.cxx: In constructor
> ‘{anonymous}::FullTextEncodingData::FullTextEncodingData()’:
> core/sal/textenc/textenc.cxx:397:68: error: ISO C++ says that these are
> ambiguous, even though the worst conversion for the first is better than
> the worst conversion for the second: [-Werror]
> core/solver/unxlngi6/inc/osl/module.hxx:156:24: note: candidate 1: void
> (* osl::Module::getFunctionSymbol(const char*) const)()
> core/solver/unxlngi6/inc/osl/module.hxx:150:24: note: candidate 2: void
> (* osl::Module::getFunctionSymbol(const rtl::OUString&))()
>
> if I stick in explicit the above goes away.

 Fortunately it also goes away if the osl::Module class gets fixed. The 
original developer of the class was sloppy with constness, whereas whoever 
added the recent OUString overload did it properly, so the ambiguity stems 
from having to chose either doing const conversion for the 'this' parameter 
or literal->OUString conversion for the normal parameter.

 But yes, this shows that this cannot be done completely carelessly. I've now 
checked a complete rebuild and there were some more cases of ambiguities, but 
only a handful of them, mostly OString vs OUString overloads. Those cases can 
be fixed by an extra overload, removing needless overload, explicit 
conversion and in some cases it even looks like the API is in fact broken 
(dbaui::OGenericUnoController::openHelpAgent() does something different for 
the overloads, INetURLObject decodes their contents differently). Still, I 
think the benefits outweight these few cases.

> I had wondered if
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#757 would
> make a difference here, but locally seems to work fine in my gcc
> with/without c++11x support

 I checked this before starting, as far as I understand it, this is triggered 
by what type is used as the template argument, but in this case the template 
operates on const char[N] and the template argument is a simple numeric 
value, so the SAL_N_ELEMENTS limitation does not apply here.

 Updated patch attached.

-- 
 Lubos Lunak
 l.lunak at suse.cz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: constascii_deprecate.patch
Type: text/x-diff
Size: 15624 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120210/c52d3a5d/attachment-0001.patch>