Age | Commit message (Collapse) | Author |
|
...otherwise, it might still run during exit(3) and cause problems.
|
|
|
|
Added:
* rtl::OString::matchL
* rtl::OString::endsWith
* rtl::OString::endsWithL
* rtl::OString::indexOfL
* rtl::OString::replaceFirst
* rtl::OString::replaceAll
* rtl::OString::getToken
* rtl::OUString::endsWith
* rtl::OUString::replaceFirst
* rtl::OUString::replaceFirstAsciiL
* rtl::OUString::replaceFirstAsciiLAsciiL
* rtl::OUString::replaceAll
* rtl::OUString::replaceAllAsciiL
* rtl::OUString::replaceAllAsciiLAsciiL
* rtl::OUString::getToken
plus underlying C functions where necessary
Deprecated:
* comphelper::string::remove
* comphelper::string::getToken
Removed:
* comphelper::string::searchAndReplaceAsciiL
* comphelper::string::searchAndReplaceAllAsciiWithAscii
* comphelper::string::searchAndReplaceAsciiI
* comphelper::string::replace
* comphelper::string::matchL
* comphelper::string::matchIgnoreAsciiCaseL
* comphelper::string::indexOfL
Also fixed some apparent misuses of RTL_CONSTASCII_USTRINGPARAM ->
RTL_CONSTASCII_STRINGPARAM.
|
|
|
|
|
|
Base needs the numberformatter to initialize a document
|
|
|
|
|
|
|
|
|
|
|
|
No behaviour change intended. However, if behaviour changed, probably the *old* behaviour is buggy, not new one.
|
|
|
|
|
|
This reverts commit 23151ab53574e0e893f4507313ff15388638746a.
Fixed root cause in previous commit.
|
|
|
|
37b5dce665a03d3404e6a710b82bef16d740d178 re-wrote a std::rotate call to cause
an "error: function requires a valid iterator range [__middle, __last)" abort
from debug-mode GCC libstdc++ during smoketest. Lionel should check whether
this fix is actually good -- at least, it causes "make check" to succeed again.
|
|
As a drive-by: fillMatrix update m_nEndSize
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
for always-true and always-false tests.
Some databases have poor or no support for booleans.
|
|
|
|
|
|
|
|
|
|
* cppheader.xsl had initially been written under the false assumption that a
missing oor:nillable attribute defaults to "false" instead of "true". That has
been fixed.
* As a result, many places that use the new simplified officecfg/*.hxx headers
broke as they did not expect value types to be wrapped boost::optional. To keep
the code simple, I decided to change all occurrences in
officecfg/registry/schema/ of properties that specify a default <value> and do
not explicitly specify oor:nillable="true" to oor:nillable="false". Strictly
speaking, this is an incompatible change, but in many cases it should be what
was intended, anyway.
* Some places that use the new simplified officecfg/*.hxx headers still had to
be adapted to boost::optional wrapping.
* This showed that unotools/configuration.hxx did not yet work for those wrapped
properties and needed fixing, too.
|
|
|
|
|
|
Caolán fixed Iterator management which was buggy. (thank you !)
|
|
|
|
When lowering m_nStartPos, do not duplicate rows above its old value
|
|
Symptom: segfault.
Thanks to Julien Nabet for precise pointer to problematic code.
|
|
SAL_UNUSED_PARAMETER (expanding to __attribute__ ((unused)) for GCC)
is used to annotate legitimately unused parameters, so that static
analysis tools can tell legitimately unused parameters from truly
unnecessary ones. To that end, some patches for external modules
are also added, that are only applied when compiling with GCC and
add necessary __attribute__ ((unused)) in headers.
|
|
|
|
As in: that the compiler won't see the variables in the condition when OSL_DEBUG_LEVEL==0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It makes no sense, because non-nullable columns can have NULL value.
E.g. in "foo LEFT JOIN bar ON condition", the non-nullable columns of "bar"
when it has no row matching "condition".
Even when we are about to insert/update a row, we should not put a
hard-coded value (that just happens to be the one constructed by the
C++ default constructor for that type) in non-nullable columns: there
is no guarantee that this value makes sense in that database's context.
The database may or may not have a default value set for that column.
If it has, we should leave it up to the database to set it automatically.
If it has not, an error *is* the right reaction.
Another place where this substitution does damage is when we refresh a
row. We use the values we have read from the primary key to select the
row again. So we should not mangle those, else the select returns no
row and we mistakingly think the row has been deleted.
|
|
|