the intent of this header has canged over time. now it is already
systematically included with ustring.hxx and the operator overload it
provide fit nicely there...
Just to be safe, since that include as been added to the api during the
3.5 timeframe and therefore is already in 'production'
the header remain and simply attempt to include ustring.hxx
but a warning is issued indicating that this header should not be used
anymore... in a couple of major release we will thenr emove it completely
All internal users of that header are converted.
Change-Id: I8934c55f089e29d78c0f5649b7c87b2ecf024bad
Reviewed-on: https://gerrit.libreoffice.org/634
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Hierarchical path is assumed in loads of places, changed the URLs to the
following:
* Binding URL is encoded in the authority part, the repository ID is
set as a fragment of the binding URL.
* The hierarchical path reflects one of the path to the document on
the server
:x
Change-Id: I8214daeb1d9c9b0f6ab86bdf60875e7e4e5369f4
ReadLine differs from std::getline with respect to final lines
that end at EOF with no EOL.
i.e. see Export::ConvertLineEnds in l10ntools/source/export2.cxx
which doesn't make a massive amount of sense the way things currently are.
Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
Nobody ever checked the return value anyway, so just return the string
and use the stream state bits if necessary to find failures.
Doesn't need to be a member, make a standalone function
Rename it to read_zeroTerminated_uInt8s_AsO[U]String, stupid perhaps,
but *shrug*, unambiguous.
Drop misleading overloaded String variants use:
read_zeroTerminated_uInt8s_AsOString or
read_zeroTerminated_uInt8s_AsOUString
added a unit test, valgrinded it, found and fixed invalid read
in original implementation.
* New SAL_INFO..., SAL_WARN... macros.
* New SAL_STREAM supersedes OSL_FORMAT.
* oustringostreaminserter.hxx moved from unotest to rtl (and always UTF-8 now).
* TODO to enable GCC __attribute__((format)) in sal/log.h (requires call-site
cleanup).
* Further functionality in tools/debug.hxx (DBG_MEMTEST, DBG_CTOR, etc.) not yet
addressed.
* Some replacements tools String -> rtl::OUString.
this aligns them with the behaviour of std::stream, and makes things
like
sal_uInt32 n(0);
rSt >> n;
if (n)
{
...
}
safe if there was a short read of e.g. 3 bytes instead of the required 4
