Obsoleting RTL_CONSTASCII_USTRINGPARAM

[Caolán McNamara]

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

> 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.


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 and throwing e.g. 

namespace
{
    const char foo[] = "apple";
}

...

CPPUNIT_ASSERT( validConversion( rtl::OUString( foo ) ));

at it, which I thought might have been a problem, but apparently not.

C.