summaryrefslogtreecommitdiff
path: root/sal
AgeCommit message (Collapse)AuthorFilesLines
2019-09-29constmethod for accessor-type methodsNoel Grandin1-1/+1
Apply the constmethod plugin, but only to accessor-type methods, e.g. IsFoo(), GetBar(), etc, where we can be sure of that constifying is a reasonable thing to do. Change-Id: Ibc97f5f359a0992dd1ce2d66f0189f8a0a43d98a Reviewed-on: https://gerrit.libreoffice.org/74269 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-24support O(U)String::number() for fast string concatenationLuboš Luňák4-23/+51
When I did the fast string concatenation, I didn't add any support for number(), which simply returned a O(U)String, and so it did the extra allocation/deallocation, although that could be avoided. In order to support this, number() now returns a special temporary return type, similarly to O(U)StringConcat, which allows delaying the concatenation the same way. Also similarly, the change of the return type in some cases requires explicit cast to the actual string type. Usage of OString::getStr() is so extensive in the codebase that I actually added it to the helper class, after that it's only relatively few cases. Change-Id: Iba6e158010e1e458089698c426803052b6f46031 Reviewed-on: https://gerrit.libreoffice.org/78873 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-09-23do not require $(SRCDIR) in every gb_Library_set_precompiled_headerLuboš Luňák1-1/+1
Change-Id: I7b3a22584bb2e4d501f509ffcd80929feed23a4c Reviewed-on: https://gerrit.libreoffice.org/79360 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-09-17Better handling of non--UTF-8 filesystem pathnames in sal/osl/unx/Stephan Bergmann11-240/+509
The idea is to internally in sal/osl/unx/ use OString instead of OUString to represent pathnames, so that the OString carries the actual bytes that make up the pathname. At the boundary of translating between pathname OStrings and file URL OUStrings, translate sequences of bytes that are valid according to osl_getThreadTextEncoding() into UTF-8 and translate other bytes into individual (percent-encoded) bytes in the file URL. This change required duplicating some of the internal functionality in sal/osl/unx/ for both OString and OUString, and to make part of sal/rtl/uri.cxx accessible from sal/osl/unx/ via new sal/inc/uri_internal.hxx. Change-Id: Id1ebaebe9e7f2d21f350f6b1a07849edee54331f Reviewed-on: https://gerrit.libreoffice.org/78798 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-16Simplify forced memory readsStephan Bergmann1-4/+3
Change-Id: I68ea0a46bcaaadb455f2f2cc6e53950e2f26a763 Reviewed-on: https://gerrit.libreoffice.org/79003 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-16-Werror=volatile (GCC 10 trunk)Stephan Bergmann1-2/+2
"error: compound assignment with ‘volatile’-qualified left operand is deprecated" in C++20 mode Change-Id: I62825237a2f4caf359f5f116ab4097ae6b9376e6 Reviewed-on: https://gerrit.libreoffice.org/78975 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-11Fix Unicode to Shift JIS/MS932 conversion dataStephan Bergmann2-5/+5
These are MS932 extensions, and per <https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT> ("Table version: 2.01", "Date: 04/15/98"), U+4F92 is a mapping for 0xFA6F (and also for 0xED53, which is also an MS932 extension, and "loses" here), and U+4F9A is a mapping for 0xFA71 (and also for 0xED55, which is also an MS932 extension, and "loses" here). (And neither U+4F92 nor U+4F9A appear as mappings in <https://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/SHIFTJIS.TXT>, "Table version: 2.0", "Date: 2011 October 14 (header updated: 2015 December 02)".) This appears to be a typo dating back to 9399c662f36c385b0c705eb34e636a9aec450282 "initial import". Change-Id: I0c699675355d839e62d6e4082355a2d67472533e Reviewed-on: https://gerrit.libreoffice.org/78720 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-10Fix typosAndrea Gelmini1-1/+1
Change-Id: I79f87f033eeb67d1750bb595d311d74ef3db6ce9 Reviewed-on: https://gerrit.libreoffice.org/78795 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2019-09-10tdf#127069 sal: preserve gid of files in the unx osl_replaceFile()Miklos Vajna1-1/+32
The w32 implementation preserves all attributes of the destination file, the unx one preserved none of them. Bring the unx osl_replaceFile() closer to the w32 by preserving the gid of the destination file as a start. [ No testcase, we support building on systems where the user is part of a single group only, and it's not possible to verify the effect of this change in such environments. ] Change-Id: I722d4802df34caf71a9dc0db1a3df8b76acb9de6 Reviewed-on: https://gerrit.libreoffice.org/78789 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-09-06Fix typo in comment (ASCII 0x42 is "B")Stephan Bergmann1-1/+1
Change-Id: Iba8411cede4dc47aaa1d9d433de2606c0d66e0bf Reviewed-on: https://gerrit.libreoffice.org/78692 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-06Fixing "...."Andrea Gelmini3-3/+3
Change-Id: I3424e17cfdfb563fdc5882942031deafae8689fe Reviewed-on: https://gerrit.libreoffice.org/78678 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-09-05Clean up {osl_,osl::}systemPathEnsureSeparator comboStephan Bergmann2-39/+8
Change-Id: Iafa953725c1ca8e6f3032945dc0700ae989519b9 Reviewed-on: https://gerrit.libreoffice.org/78671 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-05Clean up {osl_,osl::}systemPathMakeAbsolutePath comboStephan Bergmann4-56/+12
Change-Id: Iec4c2ff8c8239069f95fff195c49fac9f7c865d4 Reviewed-on: https://gerrit.libreoffice.org/78656 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-05Use OUString in osl_getNextDirectoryItemStephan Bergmann1-9/+7
Change-Id: Ifa1491a1af1d3c74d84ec4d6bec79fcf7a5d6bf4 Reviewed-on: https://gerrit.libreoffice.org/78653 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-05Fix osl_systemPathEnsureSeparator preconditionStephan Bergmann1-13/+14
Change-Id: I0165a14f159a6c2c7bce84d1ca646435146d1da0 Reviewed-on: https://gerrit.libreoffice.org/78643 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-05Let osl_systemPathEnsureSeparator directly take an OUStringStephan Bergmann2-14/+11
Change-Id: Ia9505298fe92d62d716e2c28ac0a5098c4b61121 Reviewed-on: https://gerrit.libreoffice.org/78642 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-05Fix conversion of U+0000 in ImplUnicodeToDBCSStephan Bergmann2-1/+10
...which appears to have been broken when 13824735057ef25075af8fd0ddb8f14e34c7eeb6 "#81346# - Fix for unconverted characters for DBCS encodings" moved that "if" out of surrounding "if" block. (And, for consistency, write the "if" check in the same way as the preceding one is written since 739cb04c36524c5a1bbf768dfe93624a1b2ec8b4 "#97705# Fixed mapping of Big5 EUDC points.") Change-Id: I4324197c4eba671ab6313fb89f988da102b8ffa5 Reviewed-on: https://gerrit.libreoffice.org/78627 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-04Do not exclude Unicode noncharacters from rtl_convertUnicodeToTextStephan Bergmann11-50/+110
For one, that broke round-tripping with e.g. UTF-8 (see the test case added to Test::testComplex in sal/qa/rtl/textenc/rtl_textcvt.cxx) which did not treat noncharacters as invalid. For another, <https://unicode.org/faq/private_use.html#nonchar7> is meanwhile quite clear on the matter: "Q: Are noncharacters prohibited in interchange? "A: This question has led to some controversy, because the Unicode Standard has been somewhat ambiguous about the status of noncharacters. The formal wording of the definition of 'noncharacter' in the standard has always indicated that noncharacters 'should never be interchanged.' That led some people to assume that the definition actually meant 'shall not be interchanged' and that therefore the presence of a noncharacter in any Unicode string immediately rendered that string malformed according to the standard. But the intended use of noncharacters requires the ability to exchange them in a limited context, at least across APIs and even through data files and other means of 'interchange', so that they can be processed as intended. The choice of the word 'should' in the original definition was deliberate, and indicated that one should not try to interchange noncharacters precisely because their interpretation is strictly internal to whatever implementation uses them, so they have no publicly interchangeable semantics. But other informative wording in the text of the core specification and in the character names list was differently and more strongly worded, leading to contradictory interpretations. "Given this ambiguity of intent, in 2013 the UTC issued Corrigendum #9, which deleted the phrase 'and that should never be interchanged' from the definition of noncharacters, to make it clear that prohibition from interchange is not part of the formal definition of noncharacters. Corrigendum #9 has been incorporated into the core specification for Unicode 7.0. "Q: Are noncharacters invalid in Unicode strings and UTFs? "A: Absolutely not. Noncharacters do not cause a Unicode string to be ill-formed in any UTF. This can be seen explicitly in the table above, where every noncharacter code point has a well-formed representation in UTF-32, in UTF-16, and in UTF-8. An implementation which converts noncharacter code points between one UTF representation and another must preserve these values correctly. The fact that they are called 'noncharacters' and are not intended for open interchange does not mean that they are somehow illegal or invalid code points which make strings containing them invalid." Change-Id: I4fcc0156e3d2fd305a7c7bb0c7b3dbef846c9e64 Reviewed-on: https://gerrit.libreoffice.org/78598 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-04[API CHANGE] rtl_convertTextToUnicode behavior upon erroneous inputStephan Bergmann13-32/+195
<http://udk.openoffice.org/cpp/man/spec/textconversion.html> specifies that FLAGS_UNDEFINED_ERROR, FLAGS_MBUNDEFINED_ERROR, and FLAGS_INVALID_ERROR: "Read past the [erroneous] code in the input buffer [...]" But actual behavior of rtl_convertTextToUnicode for the various rtl_TextEncoding values has been inconsistent. Some erroneous input (mostly single-byte UNDEFINED and INVALID ones) has not been consumed at all, some (multi-byte MBUNDEFINED and INVALID) has been consumed partly, and some has been consumed fully as required. However, at least since 8dd4265b9ddbd7786b6237676909eae5b540da0e "CWS-TOOLING: integrate CWS hb18", Custom8BitToUnicode in sw/source/filter/ww8/ww8par.cxx appears to rely on the broken behavior of not consuming erroneous input. (It reads the chunk of valid input with e.g. some RTL_TEXTENCODING_MS_125x that happens to exhibit the broken behavior of not consuming erroneous input, then wants to try to re-read the erroneous input with RTL_TEXTENCODING_MS_1252. For example, opening sw/qa/core/data/ww8/pass/forcepoint50-grfanchor-1.doc triggers that code. For whatever reason, the am_faksas.dot attached to <https://bz.apache.org/ooo/show_bug.cgi?id=9240#c1> "Do not show lithuanian letter 'Š'" appears to not, or at least no longer, trigger that code.) Therefore, it would be useful to have a mode in which rtl_convertTextToUnicode does not consume erroneous input. (And I plan on doing changes in sal/osl/unx/file* that would benefit from that behavior, too.) But changing rtl_convertTextToUnicode to generally not consume erroneous input would not be feasible: If calls do not set RTL_TEXTTOUNICODE_FLAGS_FLUSH, part of an erroneous input can already have been consumed by a previous call, so the current call cannot undo that. But a change that looks like it can work is to change the behavior only if RTL_TEXTTOUNICODE_FLAGS_FLUSH is set. In that case we can at least not consume the part of an erroneous input that has not yet been consumed by a previous call (which would necessarily have been done with RTL_TEXTTOUNICODE_FLAGS_FLUSH unset). The expecation is that code that relies on the don't-consume behavior will do only single calls with RTL_TEXTTOUNICODE_FLAGS_FLUSH set (so reliably not consume the complete erroneous input), while other code (which might do calls in a loop) will not care whether erroneous input has been consumed, anyway. This can be considered a mild form of behavioral API CHANGE (but note that the old implementation didn't exhibit the requested behavior anyway). So all implementations of rtl_convertTextToUnicode for the various rtl_TextEncoding values have been adapted to the new behavior. The only exceptions are ImplDummyToUnicode (sal/textenc/textcvt.cxx), which is a special case anyway used by RTL_TEXTENCODING_DONTKNOW, and two out of three places (marked with a "TODO" each) in ImplUTF7ToUnicode (sal/textenc/tcvtutf7.cxx), where it is hard to retrofit the expected behaivor, and RTL_TEXTENCODING_UTF7 is probably not relevant for the use cases relying on the don't-consume--behavior, anyway. Whether a similar change should be done for rtl_convertUnicodeToText can be examined later. Change-Id: I1ac2c4cfd99e2a0eca219f9a3855ef110b254855 Reviewed-on: https://gerrit.libreoffice.org/78584 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-03Fix handling of invalid bytes >= 0x80 in ImplUTF7ToUnicodeStephan Bergmann2-7/+31
Change-Id: I08838f9ae34a31712d7269ddaaee3fe59ece2178 Reviewed-on: https://gerrit.libreoffice.org/78562 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-09-01Resolves: ofz#16898 Direct-leak in rtl_uString_ImplAllocCaolán McNamara1-2/+2
Change-Id: I7bc11108790f8d87396bad3a2c5c2280f8f7d59a Reviewed-on: https://gerrit.libreoffice.org/78369 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-30Blind fix for Android, take twoStephan Bergmann1-1/+1
After 1928ced074260d2d40345bdf4c96767abb99bb4f "Blind fix for Android", tb24 still fails with > Linking obj/local/armeabi-v7a/liblo-native-code.so > /home/android/lo/master-android-arm/instdir/program/libsofficeapp.a(sofficemain.o):sofficemain.cxx:function soffice_main: error: undefined reference to ´sal_detail_initialize´ > clang++: error: linker command failed with exit code 1 (use -v to see invocation) Lets see if including sal/osl/unx/salinit.cxx in ANDROID/iOS builds works (even if the contents is not normally used there, including it should be harmless). Change-Id: Ifa38af8f5217a17d3ac74851b46bdb3b50cd4efd Reviewed-on: https://gerrit.libreoffice.org/78325 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-30Extract common code from #if/#else blocksStephan Bergmann1-9/+7
Change-Id: I7d14fd76ec4e571d5971131b5ee16f4dfe648b23 Reviewed-on: https://gerrit.libreoffice.org/78316 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-30Replace is_soffice_Impl hack with a better(?) hackStephan Bergmann6-38/+64
...that involves adding a second, one-off special meaning to the existing sal_detail_initialize function. This at least gets rid of the "osl_getExecutableFile contains 'soffice' substring" guesswork (and of the osl_systemPathGetFileNameOrLastDirectoryPart call there, which is what I'm actually after, for a different change to come). Change-Id: I4dd6eef1fd0411bf66943ffea415876c92d08526 Reviewed-on: https://gerrit.libreoffice.org/78291 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-30Clean up some osl::X, X_u function combosStephan Bergmann5-63/+26
(adapting call sites where necessary) Change-Id: Ib9ad1122571b1c00ebbb4638f94eb5698b18a1a7 Reviewed-on: https://gerrit.libreoffice.org/78289 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-29Make oslDirectoryImpl a bit more C++yStephan Bergmann1-18/+20
Change-Id: Iff5e26369889345d1f907e52d86eff6b89c63e20 Reviewed-on: https://gerrit.libreoffice.org/78260 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-27Avoid declaring function templates in namespace stdStephan Bergmann2-12/+16
...that don't even depend on program-defined types Change-Id: I102ce7e97280e7b80f8270ab3b7bbdc111d4d68c Reviewed-on: https://gerrit.libreoffice.org/78168 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-24loplugin:returnconstval in sal..scNoel Grandin2-11/+8
Change-Id: I300d14d580d450ec338129918955651b9d40d5d2 Reviewed-on: https://gerrit.libreoffice.org/78059 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-08-20Fix typosAndrea Gelmini3-15/+15
Change-Id: Ib61f500f7f9199e524d6ba4de419eda7fb30abcf Reviewed-on: https://gerrit.libreoffice.org/77761 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-20Fix typosAndrea Gelmini2-2/+2
Change-Id: I5db25074d42fa22f3e36969cb561ad64c1e96dc1 Reviewed-on: https://gerrit.libreoffice.org/77760 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-08-13Avoid non-async-signal-safe functionality after forkStephan Bergmann1-4/+6
Triggering those SAL_WARN sporadically caused deadlocks at least for <https://ci.libreoffice.org/job/lo_ubsan/>. Change-Id: I7b7037e411c29eea26e63f71a5679127b084f447 Reviewed-on: https://gerrit.libreoffice.org/77374 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-12Avoid non-async-signal-safe functionality between fork and execStephan Bergmann1-2/+1
This is a partial revert of 17642437fe0d68cf868ab430f04b4fdc12f1767f "reduce ifdef forest". The original code used unsetenv only for certain platforms, and putenv for others, but code a few lines further down uses unsetenv unconditionally, so assume that it is safe to use on all relevant platforms these days. unsetenv isn't listed as async-signal-safe at <http://pubs.opengroup.org/ onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03> "Signal Actions" (but is already used a few lines further down, also between fork and exec), but at least we get rid of the memory management involved in the OUString instance. Change-Id: Iac993db8819d40a0841c455ed04ff9ca2ee2e4eb Reviewed-on: https://gerrit.libreoffice.org/77368 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-10cid#1452268 Uninitialized scalar variableCaolán McNamara1-0/+2
Change-Id: I8b9d8f80bbf3d7d9c060d2da4675ae832966c085 Reviewed-on: https://gerrit.libreoffice.org/77242 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-10loplugin:stringconstant (macOS)Stephan Bergmann1-1/+1
Change-Id: Icb9d9e1cd21e2506e36fe40a3b93b6a2521a868c Reviewed-on: https://gerrit.libreoffice.org/77239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-10aTime.tm_wday gets overwritten anywayCaolán McNamara1-1/+0
so drop the first write in favor of the second Change-Id: Iac906d806a66e010e8352139b555aef6078bda02 Reviewed-on: https://gerrit.libreoffice.org/77235 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-09Resolves: tdf#126766 fix rounding correction at start of negative valuesEike Rathke1-2/+12
doubleToString() is entered with an inaccuracy afflicted fValue=-9999.9999999999927 for which the rounding into the next magnitude incremented the '-' character to '.' instead of appending a '1' (and '0' and then "000") thus yielded ".0000" instead of "-10000" This seems to have been always the case. Change-Id: I66170defa71fec40ca0b85f68affde8eff0d5ccb Reviewed-on: https://gerrit.libreoffice.org/77208 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2019-08-02Fix typo in codeAndrea Gelmini1-1/+1
Change-Id: Ie32bb0cf7f987ab57dc03d1485535a1019fd111a Reviewed-on: https://gerrit.libreoffice.org/76853 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2019-08-02Fix typosAndrea Gelmini16-35/+35
Change-Id: Ie183c445bf8a545f59aac7b0e29f72ab679a6cf3 Reviewed-on: https://gerrit.libreoffice.org/76852 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
2019-08-01Silence -Wunused-function on AndroidMike Kaganski1-0/+4
after commit bf6bde2da134dad60ecbf8f3e97674abadb7349e Change-Id: Iaf6f1457f95e5b821879b735c16a692cca7515db Reviewed-on: https://gerrit.libreoffice.org/76791 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-08-01Unify some code across platforms to use static initializersMike Kaganski1-113/+101
Static initializers were used for the environment strings since commit d19c40f45dc8e8bcd9db4c6b83bdcf6367f6fbe7 to workaround thread-unsafe getenv. The special case for Android was initially introduced in commit 60628799633ffde502cb105b98d3f254f93115aa, to allow modifying the environment in the code; then was fixed in commit 4fbf6df784529d48cf194a2d9c495ffb47933d59. That was relying on the functions being called each time their results were used. But commit 9f027559557cb132835d8a13cdc0281ad4e757ae changed that, making the results static, thus only calling the functions once on all platforms. This was effective more than a year already, so presumably the special-casing for Android isn't needed anymore. Thus, this patch unifies all platforms to use the same approach (calling getenv once, storing copies of result in static variables. Also this stores flags used in maybeOutputTimestamp to static variables, too, to avoid parsing strings each time the function is called. Change-Id: I84bdbfb900c15b407fb555296d2613bd3d62da7e Reviewed-on: https://gerrit.libreoffice.org/76573 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-08-01Sometimes static checks are enough.Mike Kaganski1-2/+4
Change-Id: I61e7a28c5beab8f0c619767545009cefae6ddcd9 Reviewed-on: https://gerrit.libreoffice.org/76772 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-07-31Improved loplugin:stringconstant (now that GCC 7 supports it): salStephan Bergmann3-3/+3
Change-Id: Id9d994343d10b5d5e852b10946c036dfbeb66d04 Reviewed-on: https://gerrit.libreoffice.org/76656 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-30Fix typosAndrea Gelmini1-1/+1
It passed "make check" Change-Id: I50c3639ec258c7fb6d73104f8e777f96995aa8e3 Reviewed-on: https://gerrit.libreoffice.org/76543 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-07-24Fix typoAndrea Gelmini1-1/+1
"an URI", to complete: https://gerrit.libreoffice.org/#/c/75985/ Change-Id: I57489b05117fd12ae6aa22544437ab5bc6b5154f Reviewed-on: https://gerrit.libreoffice.org/76037 Tested-by: Jenkins Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
2019-07-19cid#1448293 Copy into fixed size bufferCaolán McNamara1-1/+2
Change-Id: I0ff36c58bf2448bdccc239582ba24b69c7431c6d Reviewed-on: https://gerrit.libreoffice.org/75921 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-19coverity concurrency annotation attemptNoel Grandin1-0/+20
Let us see what happens if we annotate our mutex code, https://scan.coverity.com/models Change-Id: I7baf44d1a252f19b4ae47f3a6b318f7ccd9629d7 Reviewed-on: https://gerrit.libreoffice.org/75851 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-18cid#1448288 Unchecked return value from libraryCaolán McNamara1-1/+1
Change-Id: Id1b8044126e65e67b2496cf7a4eb86b54ba6c1df Reviewed-on: https://gerrit.libreoffice.org/75872 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-07-09Optimize osl_getSystemTime on WindowsMike Kaganski1-16/+20
Make OffTime static const; don't cast from FILETIME to __int64 (see https://docs.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime for explanation: "it can cause alignment faults on 64-bit Windows"). Instead, cast in opposite direction: from 8-byte-aligned 64-bit integer to FILETIME. Change-Id: Iba61cc0198f8f25ef471d87e661c8801724b913d Reviewed-on: https://gerrit.libreoffice.org/75256 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-06-25improve loplugin:simplifyconstructNoel Grandin1-3/+3
Change-Id: If863d28c6db470faa0d22273020888d4219e069e Reviewed-on: https://gerrit.libreoffice.org/74559 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-06-21android: Fix type of a C string to be const char[].Jan Holesovsky1-4/+6
With the wrong type, we were measuring the sizeof() wrongly, leading to a hard to catch crash at start that appeared only from time to time. Improve the concatenation too when at that. Change-Id: I4a4ab2909124281aac99118d66c62d669294d5f7 Reviewed-on: https://gerrit.libreoffice.org/74375 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/74444 Tested-by: Jenkins
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-27 22:37:11 +0000