l.lunak at suse.cz
Fri Feb 10 02:30:54 PST 2012
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
> 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.
l.lunak at suse.cz
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 15624 bytes
Desc: not available
More information about the LibreOffice