summaryrefslogtreecommitdiff
path: root/sal/qa
AgeCommit message (Collapse)Author
2018-08-10Fix typosAndrea Gelmini
Change-Id: I98d9120160fb652cae490513765670f447cf5911 Reviewed-on: https://gerrit.libreoffice.org/58791 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2018-08-06Add missing sal/log.hxx headersGabor Kelemen
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it. This is a continuation of commit 6ff2d84ade299cb3d14d4110e4cf1a4b8070c030 to be able to remove those unneeded includes. This commit adds missing headers to every file found by: grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG') in files formerly omitted for oversight or non-cxx extension Change-Id: I327c573f44076c6ccfecf737eafccba2da72e1bd Reviewed-on: https://gerrit.libreoffice.org/58600 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-08-06loplugin:useuniqueptr in sal/qa/OStringBufferNoel Grandin
Change-Id: Ib05e209bfe71bacca99862f0e3266008bb436995 Reviewed-on: https://gerrit.libreoffice.org/58569 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-02[API CHANGE] add some more asserts to the string functionsNoel Grandin
rtl_[u]String_alloc now requires that the length be >= 0. Since this function is only @since Libreoffice 4.1, it is unlikely to be widely used externally. Removed some unit tests that were testing invalid or out of range paramers, which are already not allowed according to the documented contract of those functions. The change in writerfilter is because the new asserts triggered when running testFdo74745 The change in SwTextNode::EraseText is because testFdo60842 triggered the assert in replaceAt. The change in SwFieldSlot::SwFieldSlot is because testMoveRange::Import_Export_Import triggered the assert in replaceAt. The changes in SwFieldSlot::SwFieldSlot and TabControl::ImplGetItemSize are due to failures in the uitests. Change-Id: Ib317261067649b0de96df12873ce31360cd24681 Reviewed-on: https://gerrit.libreoffice.org/58390 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-08-02Revert rtl_alloc_preInit back to boolean argumentStephan Bergmann
This effectively reverts 271a663d2f098f3f665cab6da2e13b265a7eab93 "rtl: support start/stop threads around pre-init" again, now that df6ba650469a6f2fda06ef1c2e107ccdd3570505 "Remove 'officially dead now' rtl_cache slab allocator mechanism" removed the wsupdate thread. (rtl_alloc_preInit is an internal-use-only C function, so changing its arguments doesn't affect URE compatibility.) Change-Id: Ie9bce86377f9520e2600e4111ac525dddace10f8 Reviewed-on: https://gerrit.libreoffice.org/58443 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-07-10tdf#42949 Fix IWYU warnings in include/osl/*hxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I7b19938246ca8498fa300f781589bf17b3d486aa Reviewed-on: https://gerrit.libreoffice.org/56723 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-07-08tdf#84323 - sal - add sane sleep interface: cleanup osl_waitThreadKevin Dubrulle
Replace osl_waitThread by osl::Thread::wait. Use std::chrono instead of TimeValue. Change-Id: I71691d014feeeb0c5d0ba29d048bda8e25e6e7dd Reviewed-on: https://gerrit.libreoffice.org/57130 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-06-29Improved loplugin:redundantcast (const-qualified typedefs): salStephan Bergmann
Change-Id: I64b6ffd3e43f14c5884bf6cf1c12ff3b147db6bd Reviewed-on: https://gerrit.libreoffice.org/56699 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-06-12tdf#96099 Remove some trivial std::vector typedefsArkadiy Illarionov
Cleanup package, reportdesign, sal. Change-Id: I8622465886f7ec97700b00740ea37d40767ec98e Reviewed-on: https://gerrit.libreoffice.org/55616 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2018-06-05sal: WNT -> _WIN32Thorsten Behrens
Still some holdouts from that bad old habit it seems. Change-Id: Ib0fe2c7eb006649b121668c549ff8e0bb060e120 Reviewed-on: https://gerrit.libreoffice.org/55331 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-06-01loplugin: look for CPPUNIT_ASSERT_EQUALS with params swappedNoel Grandin
idea originally from either tml or moggi, can't remember which Change-Id: Id78d75035036d3aa1666e33469c6eeb38f9e624d Reviewed-on: https://gerrit.libreoffice.org/55126 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-04-16loplugin:useuniqueptr in sal/qa/Noel Grandin
Change-Id: I20b5cfe2fd95da3f37a6812af5683bcc4d918b06 Reviewed-on: https://gerrit.libreoffice.org/52882 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-03-05Make LibreOffice buildable on Haiku.Kacper Kasper
* Obviously VCL wiring is missing, but most components do build. Change-Id: Ie853ada1423a8f4c2b647be59cd47a7730c42978 Reviewed-on: https://gerrit.libreoffice.org/50293 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2018-02-24Fix typosAndrea Gelmini
Change-Id: Ie1cff6b690e69d23c16a1a60ef4271d6cf48c13b Reviewed-on: https://gerrit.libreoffice.org/50260 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2018-01-30Typ-o negativIlmari Lauhakangas
Fixed some typos and translated a couple of German words Change-Id: I24ae28dd537ba283a9480413659f85bd6711acad Reviewed-on: https://gerrit.libreoffice.org/48892 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2018-01-23Add unit tests for rtl::math's inverse hyperbolic functionsTakeshi Abe
based on i#97605's test cases. Change-Id: Id7e57914553ba8801a624f667979badc191108e5 Reviewed-on: https://gerrit.libreoffice.org/46152 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com>
2018-01-23More loplugin:cstylecast on WindowsStephan Bergmann
Automatic rewrite (of loplugin:cstylecast and loplugin:unnecessaryparen) after cab0427cadddb3aaf1349c66f2fa13a4234ba4b2 "Enable loplugin:cstylecast for some more cases" and a409d32e7f6fc09e041079d6dbc3c927497adfed "More loplugin:cstylecast" Change-Id: Ib3355159dd08333e1b7a8d091caf2069cdcc7862 Reviewed-on: https://gerrit.libreoffice.org/48317 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-01-17tdf#114939: Verify rtl_digest_SHA1 computes broken results, by designStephan Bergmann
This replaces the known-failing test from 8d2da0b94ac5d679ef697683cacb2c83498cc497 "sal: Add rtl_digest_SHA1 which shows wrong sha1 calculation" with the known-succeeding one (though producing wrong results) from tdf#114939 "rtl_digest SHA1 and MD5 code both have an off by 1 bug". Change-Id: Ib4e8210e1889e5ebf4979d7b1f28f1cfb13ebab9 Reviewed-on: https://gerrit.libreoffice.org/48033 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2018-01-16tdf#114939 sal: fix endMD5() off-by-oneMichael Stahl
Because of the odd non-standard rtl_digest_rawMD5() API that is apparently necessary for MS Office interop, and there not being any good reason for bug-compatibility here, just fix the bug. Change-Id: Iaa0f0af4e24a5ddb9113c1ebd126f9822b5af1f6
2018-01-12More loplugin:cstylecast: salStephan Bergmann
auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable loplugin:cstylecast for some more cases" plus solenv/clang-format/reformat-formatted-files Change-Id: I7d89b011464ba5d2dd12e04d5fc9f65cb4daebde
2018-01-02Remove broken testStephan Bergmann
...introduced with 26be5f21cebfe9acad088a1086f97eebdb437b7c "unotools: don't go belly-up if temp dir is wrong or empty". At least Flatpak builds can create a /not/found/dir directory just fine. Change-Id: I73115ac99498ac584be77153ef66bba3036392c3 Reviewed-on: https://gerrit.libreoffice.org/47267 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-29loplugin:unnecessaryparen improve return checkNoel Grandin
Change-Id: I8128aa4b5fc60efd1dbf5971cdde11e588f5f64b Reviewed-on: https://gerrit.libreoffice.org/47167 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-12-28rtl: support start/stop threads around pre-initAshod Nakashian
This is necessary to avoid having extra threads while forking. After forking, the second stage of pre-init is started and so we start the stopped rtl threads. The comment for rtl_alloc_preInit_phase_t has more details. Change-Id: I1a3f7be74d4b04d0b2fc4a72b02124c2faa3c047 Reviewed-on: https://gerrit.libreoffice.org/47060 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
2017-12-22unotools: don't go belly-up if temp dir is wrong or emptyJuergen Funk
When a wrong temp directory was set (e.g. wrong path in xcu ist set), you get a assert in the LO-Debug Version, this patch avoid this assertion. Change-Id: I192f682860ad9cddf907e4b239eff36b4bd6072d Reviewed-on: https://gerrit.libreoffice.org/46846 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2017-12-20Don't use -I$(SRCDIR), people have various strange stuff in the SRCDIR.Jan Holesovsky
For me, the build failed because of a file named 'new' ;-) Change-Id: I1816ff16b1b76a833ded2b6f332553b768916cad Reviewed-on: https://gerrit.libreoffice.org/46776 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jan Holesovsky <kendy@collabora.com>
2017-12-17Fix typosAndrea Gelmini
Change-Id: I4630ba4a93a32c47753422b29535c36b53ff3d5e Reviewed-on: https://gerrit.libreoffice.org/46635 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2017-12-15sal: add pre-initialization scheme for allocations.Michael Meeks
This saves several megabytes of dirtied pages for each LOK client of Online. Change-Id: I425a2e7896879f0a64d71fcc0655e9e1fa1256aa
2017-12-11loplugin:salcall fix functionsNoel Grandin
since cdecl is the default calling convention on Windows for such functions, the annotation is redundant. Change-Id: I1a85fa27e5ac65ce0e04a19bde74c90800ffaa2d Reviewed-on: https://gerrit.libreoffice.org/46164 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-11-21Fix typosAndrea Gelmini
Change-Id: I40b3a46d46f0586d086bdbe41876c088f8c1cb58 Reviewed-on: https://gerrit.libreoffice.org/45007 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Jens Carl <j.carl43@gmx.de>
2017-11-11Avoid using O[U]StringConcat lvalues containing dangling refs to temporariesStephan Bergmann
...in code accidentally using auto like > auto const aURL = uri->getUriReference() + "/" > + INetURLObject::encode( > m_sEmbeddedName, INetURLObject::PART_FPATH, > INetURLObject::EncodeMechanism::All); > > uno::Reference<uno::XInterface> xDataSource(xDatabaseContext->getByName(aURL), uno::UNO_QUERY); in <https://gerrit.libreoffice.org/#/c/44569/1> "Properly construct vnd.sun.star.pkg URL" did (causing hard to debug test failures there). So make functions taking O[U]StringConcat take those by rvalue reference. Unfortunately, that also needed adaption of various functions that just forward their arguments. And some code in sc/qa/unit/ucalc_formula.cxx used CPPUNIT_ASSERT_EQUAL on OUStringConcat arguments in cases where that happened to actually compile (because the structure of the two OUStringConcats was identical), which needed adaption too (but which would arguably better use CPPUNIT_ASSERT_EQUAL_MESSAGE, anyway). Change-Id: I8994d932aaedb2a491c7c81c167e93379d4fb6e3 Reviewed-on: https://gerrit.libreoffice.org/44608 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-10-24Make testUtf8StringLiterals work when char is unsignedStephan Bergmann
...as is reportedly the case for Linux AArch64 Change-Id: I7e11c42f4437c8aad9dd734603fa7e0d458c9754
2017-10-23loplugin:includeform: salStephan Bergmann
Change-Id: I539ca8b9dee5edc5fc2282a2b9b0ffd78bad8b11
2017-10-05Rename and move SAL_U/W to o3tl::toU/WMike Kaganski
Previosly (since commit 9ac98e6e3488e434bf4864ecfb13a121784f640b) it was expected to gradually remove SAL_U/W usage in Windows code by replacing with reinterpret_cast or changing to some bettertypes. But as it's useful to make use of fact that LibreOffice and Windows use compatible representation of strings, this commit puts these functions to a better-suited o3tl, and recommends that the functions be consistently used throughout Windows-specific code to reflect the compatibility and keep the casts safe. Change-Id: I2f7c65606d0e2d0c01a00f08812bb4ab7659c5f6 Reviewed-on: https://gerrit.libreoffice.org/43150 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-09-27SAL: use more Unicode on WindowsMike Kaganski
Change-Id: I9f54c8e8c4e617cc1ed6b436ca8c162d381ecab3 Reviewed-on: https://gerrit.libreoffice.org/42828 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-09-24Map Windows code page 42 to RTL_TEXTENCODING_SYMBOLStephan Bergmann
<https://msdn.microsoft.com/en-us/library/windows/desktop/ dd374130(v=vs.85).aspx> "WideCharToMultiByte function" suggests that there now is CP_SYMBOL, "Windows 2000: Symbol code page (42)." And a little test program on Windows indicates that our RTL_TEXTENCODING_SYMBOL is working the same way as CP_SYMBOL, where MultiByteToWideChar maps 00..1F to U+0000..1F and 20..FF to U+F020..F0FF. At least CppunitTest_writerfilter_rtftok, when testing writerfilter/qa/cppunittests/rtftok/data/pass/EDB-18940-1.rtf, goes into case RTF_FCHARSET in RTFDocumentImpl::dispatchValue (writerfilter/source/rtftok/rtfdispatchvalue.cxx) with nParam matching aRTFEncodings[2] (i.e., a mapping from charset 2 to codepage 42, see writerfilter/source/rtftok/rtfcharsets.cxx), then passes 42 into rtl_getTextEncodingFromWindowsCodePage and obtains an unhelpful RTL_TEXTENCODING_DONTKNOW. testFdo72031 (sw/qa/extras/rtfexport/rtfexport2.cxx, CppunitTest_sw_rtfexport2) needed to be adapted, as the circled plus from the Symbol font is now internally represented as U+F0C5, not (somewhat bogusly) as U+00C5 (aka LATIN CAPTIAL LETTER A WITH RING ABOVE). But, when displayed with the Symobl font, the glyph that is actually shown remains the circled plus. Turns out changing rtl_getTextEncodingFromWindowsCodePage would start to make CppunitTest_sw_rtfimport fail: Sep 20 15:49:24 <sberg> vmiklos, with <https://gerrit.libreoffice.org/#/c/42477/>, testN823675 (sw/qa/extras/rtfimport/rtfimport.cxx) fails, the aFont.Name is not "Symbol"; sw/qa/extras/rtfimport/data/n823675.rtf contains a \fonttbl that specifies \f3 to have \fcharset2 (i.e., symbol font) and fontname "Symbol". However, RTFDocumentImpl::checkUnicode (writerfilter/source/rtftok/rtfdocumentimpl.cxx) converts m_aHexBuffer (containing "Symbol;") with nCurrentEncoding apparently being the encoding specified by \fcharset2 (i.e., now RTL_TEXTENCODING_SYMBOL instead of old RTL_TEXTENCODING_DONTKNOW), so the resulting OUString is garbage (instead of the byte-for-byte conversion to Unicode "Symbol;" that RTL_TEXTENCODING_DONTKNOW would do there); do you know whether such \fonttbl fontnames should actually be interpreted in the given \fcharset? Sep 20 15:49:24 <IZBot> gerrit: »Map Windows code page 42 to RTL_TEXTENCODING_SYMBOL« by Stephan Bergmann for master [NEW] Sep 20 15:51:15 <vmiklos> sberg: let me check if the spec covers that Sep 20 15:54:29 <mst_> sberg: i think the name is typically encoded in the font's encoding but probably they have to make a (likely undocumented) exception for symbol encoding Sep 20 15:57:46 <vmiklos> sberg: the spec only says that \fcharset is about the encoding of the content using that font, i don't see it described what would be the encoding of the font name itself Sep 20 15:58:51 <vmiklos> sberg: i'm not sure about if that encoding should or should not affect the encoding of the font name in general, but indeed at least for 2 (symbol encoding) you're right, Word doesn't encoding the font name with that encoding, either. Sep 20 15:59:30 <sberg> vmiklos, mst_, at the top of page 14 of Word2007RTFSpec9.docx I see "Note that runs of text marked with a particular font index (see \fN in the Font Table section) use the codepage for that font as given by \cpgN or implied by \fcharsetN, unless they use Unicode RTF described in the following section." Would that match what mst_ says? Sep 20 15:59:33 <vmiklos> so if it helps you case to handle at as e.g. ascii, just for that encoding, i think there would be no problem with that. Sep 20 16:00:07 <vmiklos> sberg: that still talks about the content using the font, not the strings (font names) in the font table itself, i think. Sep 20 16:01:17 <sberg> vmiklos, what's the control word to select such a font, also \fN? I don't see any such in n823675.rtf Sep 20 16:02:16 <mikekaganski> loircbot: e.g. \af3 Sep 20 16:02:31 <mikekaganski> sberg: ^ Sep 20 16:02:47 <mst_> 04d5a280beeeb6e056df68395dc9c3b3a674361b Sep 20 16:02:50 <IZBot> core - related: fdo#77979: writerfilter RTF import: read encoded font name - http://cgit.freedesktop.org/libreoffice/core/commit/?id=04d5a280beeeb6e056df68395dc9c3b3a674361b Sep 20 16:02:52 <mst_> sberg: ^ Sep 20 16:04:05 <sberg> mst_, thanks; so there's likely an (implicit?) exception for \fcharset2, as you say Sep 20 16:04:33 <mst_> that's most plausible, our own font code is full of exceptions for "symbol fonts" too Sep 20 16:05:19 <sberg> mikekaganski, ENOCONTEXT Sep 20 16:05:36 <mikekaganski> sberg: [17:01:16] sberg: vmiklos, what's the control word to select such a font, also \fN? I don't see any such in n823675.rtf Sep 20 16:06:32 <sberg> mikekaganski, so you say selection is done with \af3 instead of \f3? Sep 20 16:06:40 <mikekaganski> sberg: yes, in that case Sep 20 16:07:34 <mst_> i think there are several different keywords that apply fonts, but can't remember the whole list Sep 20 16:08:10 <mst_> \fN shoudl be one of them though Sep 20 16:22:18 <sberg> vmiklos, so who generated that sw/qa/extras/rtfimport/data/n823675.rtf, was it manually created and lacks a \cpgN before "Symbol"? Sep 20 16:29:17 <sberg> vmiklos, (after further reading of the RTF spec): disregard the "and lacks a \cpgN before 'Symbol'" part of my above question Sep 20 16:30:27 <mst_> sberg: i suggest not reading too much about encoding in RTF, it gets pretty lovecraftian pretty fast... Sep 20 16:32:58 <vmiklos> sberg: given how short that bugdoc is, i'm pretty sure i cut it down manually to something readable from a multi-MB real bugdoc Sep 20 16:33:07 <sberg> mst_, do you have a recommendation how I could get that "don't use symbol font encoding to read a symbol font's name" into writerfilter/source/rtftok/rtfdocumentimpl.cxx? RTFDocumentImpl::checkUnicode lacks the context to tell whether it is using m_aStates.top().nCurrentEncoding to convert a fontname, and the caller of checkUnicode (at the end of RTFDocumentImpl::resolveChars in this case) appears to lack the context, too Sep 20 16:33:12 <mst_> various Old Ones from The Time Before Unicode and their Backward Compatibility Tentacles etc. Sep 20 16:34:59 <sberg> vmiklos, anyway, that "so there's likely an (implicit?) exception for \fcharset2" hypothesis sounds sane, so we should probably implement it (if only you or mst_ can give me a good hint how...) Sep 20 16:35:13 <vmiklos> sberg: looking for a code pointer Sep 20 16:36:05 <mst_> sberg: m_aStates.top().eDestination == Destination::FONTENTRY should be the relevant check? Sep 20 16:36:17 <vmiklos> sberg: RTFDocumentImpl::text() is where the text is taken, Destination::FONTENTRY is the state on the parser stack which is a font entry in the font table. so to detect "your case" during decoding a byte array into a string, m_aStates.top().eDestination == Destination::FONTENTRY is what you want Sep 20 16:36:35 <vmiklos> ah good, two independent matching hints are promising ;) Sep 20 16:37:35 <sberg> mst_, vmiklos, ah; but what also looks dodgy is that checkUnicode operates there on "Symbol;" including the closing ";" of the full <fontinfo>, not just the <fontname> part of the <fontinfo> Sep 20 16:39:24 <vmiklos> sberg: i think we already assume that the only "token" in the font entry destination that is not bound to a control world (\foo) is the font name Sep 20 16:40:52 <vmiklos> sberg: writerfilter/source/rtftok/rtfdocumentimpl.cxx:1237 is where we simply strip away the trailing semicolon, there is no further separation between the font name and other character content inside the destination (apart from the control words and their arguments) Sep 20 16:42:18 <sberg> vmiklos, OK, thanks; I'll just pretend I haven't seen those dodgy details :) ...so I'm switching to (somewhat arbitrarily) RTL_TEXTENCODING_MS_1252 there now Change-Id: Iebd1bcecb7fa71c489798154d3356062b052775e Reviewed-on: https://gerrit.libreoffice.org/42477 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
2017-09-22Windows: avoid dependence on UNICODE define; prefer W functionsMike Kaganski
Change-Id: I95b90128e93f0d88ed73601bcc5a7ca9279d4cf1 Reviewed-on: https://gerrit.libreoffice.org/42560 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-09-18Some more WIN32_LEAN_AND_MEANMike Kaganski
Change-Id: Iadb0ebb66809c192fb817b8c7cf2f8cdb4d0b874 Reviewed-on: https://gerrit.libreoffice.org/42419 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2017-09-13Make reading UTF-8 strictStephan Bergmann
Consider non-shortest forms, surrogates, and representations of values larger than 0x10FFFF (which can even cover five or six bytes, for historical reasons) as "invalid" (they used to be considered as "undefined" instead). This is in response to fc670f637d4271246691904fd649358ce2e7be59 "svtools: HTML import: don't put lone surrogates in OUString" (which can now be reverted again in a follow-up commit). My fear would have been that some places in the code rely on the original, relaxed handling, but at least 'make check' still succeeded for me. Change-Id: I017e6c04ed3c577c3694b417167f853987a1d1ce
2017-07-25tell msvc our source code is written using utf-8Caolán McNamara
Change-Id: I4fb364ceb34e0851f2d04c403333bf428e8cfa98 Reviewed-on: https://gerrit.libreoffice.org/40305 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2017-07-24fix use after delete in osl::Pipe dtorCaolán McNamara
drop down the the c api so we can truly pass ownership of the handle to xNoAcquirePipe Change-Id: I12acbec81726ae4a451b501bea5492a5865c0cc4
2017-07-23coverity#1415617 Resource leakCaolán McNamara
Change-Id: Ib23bbd9403f44fd7aa3635a3febb6533b1f9edad
2017-07-22osl: give condition tests more descriptive namesChris Sherlock
Change-Id: Iac83de722e5c3ee350e1588940567fc67a79e045
2017-07-22osl: condition qa remove extraneous commentsChris Sherlock
Change-Id: I2db888e3260543563d8c6ea5b0575e46e98df9d7
2017-07-21osl: fix Pipe noacquire/acquire testsChris Sherlock
There is an incomplete test of ::osl::Pipe::Pipe(oslPipe, __sal_NoAcquire), but the comments show that the tester wasn't able to figure out a way to test the noacquire variant of this constructor. However, they seem to have not just given up but copied and pasted the acquire and no acquire tests - the error codes for the acquire test talk about non-acquisition and don't actually see if the handle is the same or not. I have fixed this test. To test if the noacquire is working or not then you merely have to: 1. create a new Pipe instance 2. create a new Pipe non-acquired instance copy of the first instance 3. delete the non-acquired instance copy 4. try to send a single character to the original Pipe instance, which should return an error (negative return result) because at this point there is no valid pipe to operate on as the pipe should have been destroyed when you deleted the copy. If the send() succeeds, then this is a test failure. For the acquire test, it didn't actually test if the handles are the same - I have corrected this now. Change-Id: If868746233d3a222cc6f9e7cd0d453e70ef6c7cc Reviewed-on: https://gerrit.libreoffice.org/40102 Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com> Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
2017-07-18osl: update named pipe handle test namesChris Sherlock
Change-Id: I7c4da48b372c70cea51d8318aba384b9c605c5e1 Reviewed-on: https://gerrit.libreoffice.org/40113 Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com> Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
2017-07-18osl: pipe test remove unnecessary comment cruftChris Sherlock
Change-Id: I3bbf7cd131804e6788f91ec7418644cb73c62458 Reviewed-on: https://gerrit.libreoffice.org/40107 Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com> Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
2017-07-17RTL_UNICODETOTEXT_INFO_{DEST|SCR}BUFFERTOSMALL should use TOO, not TOChris Sherlock
I have kept the old mispelled constant for backwards compatibility Change-Id: I128a2eec76d00cc5ef058cd6a0c35a7474d2411e Reviewed-on: https://gerrit.libreoffice.org/39995 Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com> Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
2017-07-13use more OUString::operator== in forms..salNoel Grandin
Change-Id: I70d7e50f8c1e019524ccad915f0cca912c5035dc Reviewed-on: https://gerrit.libreoffice.org/39899 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-10simplify some OUString compareTo callsNoel Grandin
to either startsWith or == or != Change-Id: Ie4b4662f5b8e4532cbc1ab36910389e0b3d41ef0 Reviewed-on: https://gerrit.libreoffice.org/39750 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-06use OString::operator== in preference to ::equalsNoel Grandin
Change-Id: Ib291521963a791a9c6175964571e9d9895072acf Reviewed-on: https://gerrit.libreoffice.org/39646 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-01-11 06:45:21 +0000