This thing is defined by MS-OSHARED, there FWIW, the 8 bit encoding is "ANSI",
which is somewhat useless, use the same GetCharSetFromLanguage() attempt we use
elsewhere when that problem arises
Change-Id: I6d8efdbec0daf7f3439283f2be0473b6fad1fb17
Reviewed-on: https://gerrit.libreoffice.org/36214
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
...in preparation of teaching loplugin:redundantcast about C-style casts in
macro bodies.
TRGB_COLORDATA contained a curious cast to sal_Int32 (instead of sal_uInt32 aka
ColorData), but for one that affected (by accident?) only the fist term of the
... | ... | ... | ... expression (so the ultimate expression was of type
sal_uInt32), and for another before a83698b980424be214829b3ee7cdbf8d2a778755
"tools: split out color macros into own header" there were two different
definitions of TRGB_COLORDATA, and only one casted to sal_Int32 (the other to
ColorData).
Change-Id: I5bfffe5614d0424202268ef7adaf6a0da61ec30a
Reviewed-on: https://gerrit.libreoffice.org/35679
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Could have sworn I did this originally, somehow it got lost.
Also fix a thinko in tools::ResId I introduced in commit
2b70fb58be039fbd05ea833a40b1b3e9f922e45c
"Use o3tl::strong_int on RESOURCE_TYPE"
Change-Id: Id3b39962255297010cd1feaaca6d822168311081
Reviewed-on: https://gerrit.libreoffice.org/35108
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...from function definitions occurring within class definitions. Done with
a rewriting Clang plugin (to be pushed later).
Change-Id: I9c6f2818a57ccdb361548895a7743107cbacdff8
Reviewed-on: https://gerrit.libreoffice.org/34874
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
INetMIMEEncodedWordOutputSink had been intended to encode (non-ASCII) content of
a "free-form text" header field as per RFC 2047. It used a heuristic trying to
detect already encoded words (=?...?...?...?=) in the input, to pass them
through unmodified. (Arguably, it could just as well have encoded them,
assuming they were meant to be genuine input.) However, that heuristic had a
bug ever since 8ab086b6cc054501bfbf7ef6fa509c393691e860 "initial import", going
from STATE_FIRST_EQUALS to STATE_FIRST_EQUALS instead of STATE_FIRST_QUESTION,
rendering the heuristical detection logic effectively unused.
Instead of fixing the bug, 6e12729f715f142140d220dc7d3b28a4a0657016 "remove
unused enumerator from EncodedWordState" and
b8d8fb3f0cf4a961bbff54523eaca1a4f8179c7a "convert EncodedWordState to scoped
enum" crippled the code further by removing any reputedly unused cases.
But the only remaining use of INetMIMEEncodedWordOutputSink is in
INetMIMEMessage::SetHeaderField_Impl, encoding MIME-Version, Content-Transfer-
Encoding, Content-Type, and Content-Disposition header fields. And none of
those headers have any "free-form text" content that should be encoded as per
RFC 2047. The first two have fixed ASCII-only content ("1.0" and "7bit",
"8bit", etc., respectively), while the latter two have structured content that
may contain parameters of arbitrary content, which must be encoded according to
RFC 2231 (but currently isn't).
And the only place where such arbitrary-content parameters are generated is in
the two calls to SetContentTransferEncoding in
forms/source/component/DatabaseForm.cxx. (The calls to SetContentType there and
in tools/source/inet/ itself are all known to have unproblematic ASCII-only
content.) So mark those two places with TODOs about the missing encoding (which
had been missing since forever) and, in INetMIMEMessage::SetHeaderField_Impl,
liberally convert the content to 8-bit via OUString::toUtf8 for now.
Change-Id: I4b2a219b396953b219ca66441a5227157a35951f
includes ERRCODE_SFXMSG_STYLEREPLACE
which has the knock on effect that the flags argument
can be removed from a bunch of methods
Change-Id: I72b58bc2a19376bb4609e61aa44e71f734efb333
This reverts commit b5e3f8a5fa98a249ecd50021c33cf2a5c7a3b4fc.
The problem is this:
==24217== Conditional jump or move depends on uninitialised value(s)
==24217== at 0x29A25FCE: SfxObjectShell::SetError(unsigned int, rtl::OUString const&) (objmisc.cxx:220)
==24217== by 0x29A35E6E: SfxObjectShell::ImportFrom(SfxMedium&, com::sun:⭐:uno::Reference<com::sun:⭐:text::XTextRange> const&) (objstor.cxx:2300)
==24217== by 0x29A3705C: SfxObjectShell::DoLoad(SfxMedium*) (objstor.cxx:765)
==24217== by 0x29A6BC48:
SfxBaseModel::load(com::sun:⭐:uno::Sequence<com::sun:⭐🫘:PropertyValue> const&) (sfxbasemodel.cxx:1802)
The commit is bogus because it introduces a
DynamicErrorInfo::GetErrorCode(), which overloads
ErrorInfo::GetErrorCode(), which is used at least in
DynamicErrorInfo_Impl::RegisterEDcr() and used to return a constructor
argument of DynamicErrorInfo but now returns pImpl->lErrId,
which is what this statement is trying to initialize.
Ultimately this causes my clang+ASAN build to fail because the
uninitialized error code happens to be detected as a mere Warning:
Test name: testMathMalformedXml::Import
assertion failed
- Expression: !xComponent.is()
- loading succeeded: sw/qa/extras/ooxmlimport/data/math-malformed_xml.docx
Change-Id: I9141144e0bc356ee54279948f2fce036d1831a86
I can see why you'd want to hide this horrible tunnelling of
information with objects registering themselves in a global list.
Urrgh.
Change-Id: Ib151a0d2d5a4508dc456e52883e488ce56d9a095
Reviewed-on: https://gerrit.libreoffice.org/33984
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Drops a lot of duplicated code, as Idle is just a convenience
class for instant, mostly low priority timers.
Change-Id: I847592e92e86d15ab1cab168bf0e667322e48048
SvDataCopyStream used to do extra Load/Save things that are long
gone, so there is no reason for the common base anymore
Change-Id: Ib321021002adb480bb96298f199141dc3fe2ec2b
Reviewed-on: https://gerrit.libreoffice.org/32851
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
