...(that was defined iff OSL_DEBUG_LEVEL >= 2) and replace its uses with
OSL_DEBUG_LEVEL directly
Change-Id: I807c15a02cc8ced9852287df0afb4808761d19d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165067
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
and :
cid#1545983 Using invalid iterator
cid#1545969 Using invalid iterator
cid#1545949 Using invalid iterator
cid#1545929 Using invalid iterator
cid#1545911 Using invalid iterator
cid#1545910 Using invalid iterator
cid#1545886 Using invalid iterator
cid#1545870 Using invalid iterator
cid#1545813 Using invalid iterator
Change-Id: I2ad10c2a9affd348050a4abe0917a90927a52547
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160317
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...thereby silencing
> In file included from /usr/include/features.h:490,
> from /usr/include/bits/libc-header-start.h:33,
> from /usr/include/stdio.h:27,
> from soltools/mkdepend/def.h:40,
> from soltools/mkdepend/main.c:58:
> In function ‘read’,
> inlined from ‘main’ at soltools/mkdepend/main.c:197:28:
> /usr/include/bits/unistd.h:38:10: error: ‘__read_alias’ specified size 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
> 38 | return __glibc_fortify (read, __nbytes, sizeof (char),
> | ^~~~~~~~~~~~~~~
> /usr/include/bits/unistd.h: In function ‘main’:
> /usr/include/bits/unistd.h:26:16: note: in a call to function ‘__read_alias’ declared with attribute ‘access (write_only, 2, 3)’
> 26 | extern ssize_t __REDIRECT (__read_alias, (int __fd, void *__buf,
> | ^~~~~~~~~~
seen at least with -Wp,-D_FORTIFY_SOURCE=3 manually added to gb_COMPILEROPTFLAGS
in an --enable-optimized build against recent GCC 13 trunk
Change-Id: I9ca3c0ea8c579fffbdad52d7d39a4ce82085ddcd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143760
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
These occurrences of sprintf in C code don't normally trigger the deprecation
warning at least with recent macOS, because macOS by default now enables
_FORTIFY_SOURCE (see the code setting it in
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/_types.h
when originally unset), which for C code hides the declaration of sprintf (along
with its deprecation annotation) in
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/stdio.h
with a macro (expanding to __builtin___sprintf_chk) in
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/secure/_stdio.h.
But they started to trigger when I did an experimental -fsanitize=address build,
because
<b4f819086a>
"Disable source fortification on Darwin with AddressSanitizer" predefines
-D_FORTIFY_SOURCE=0 in that case.
While there might be ways to clean this code up to use something better than the
deprecated sprintf, don't bother too much with this 3rd-party, build-time--only
code and just silence any potential deprecation warnings.
Change-Id: I9f223a0ad50b2729b5d9af2db588fe9f82d0b07f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142534
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which nicely gets rid of a bunch of sprintf calls that otherwise could have
caused -Werror,-Wdeprecated-declarations with macOS 13 SDK now).
(That executable is only used during the build to process the .scp files.)
Change-Id: I3b087b11f6d3d1bce9e595322a21e67986f5d1c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142537
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 652e4ee372. Turns out on
Windows read (aka _read) actually has a parameter of type unsigned, not size_t,
(<https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/posix-read?view=msvc-170>
"read"), so this started to cause
> C:/cygwin/home/tdf/jenkins/workspace/lo_tb_master_win64_dbg/soltools/mkdepend/main.c(504): error C2220: the following warning is treated as an error
> C:/cygwin/home/tdf/jenkins/workspace/lo_tb_master_win64_dbg/soltools/mkdepend/main.c(504): warning C4267: 'function': conversion from 'size_t' to 'unsigned int', possible loss of data
(<https://ci.libreoffice.org/job/lo_tb_master_win64_dbg/34368/>) for MSVC builds
targeting x64.
Change-Id: Ica821c8b32e225b7ebbfcbd33d8b7d55515ab3e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135270
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as both malloc and read, to which this is passed, take arguments of type
size_t, not unsigned
Change-Id: I2b114c4e67bc9317d908d613fda607a12cf22579
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135347
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for places where the statements inside a block are
not indented
Change-Id: I0cbfa7e0b6fb194b2aff6fa7e070fb907d70ca2f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123885
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
so I don't read the "then" block as being a sequential statements
Change-Id: Ib2004acd3518bd4ebd2246f02a26c2c0a8bbab4c
Reviewed-on: https://gerrit.libreoffice.org/82069
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
(new with recent Clang 10 trunk) during e.g. InstallModule_scp2/ooo:
> [SPP] scp2/source/ooo/common_brand
> soltools/cpp/_tokens.c:336:13: runtime error: applying zero offset to null pointer
> #0 in copytokenrow at soltools/cpp/_tokens.c:336:13
> #1 in expand at soltools/cpp/_macro.c:325:5
> #2 in expandrow at soltools/cpp/_macro.c:292:13
> #3 in process at soltools/cpp/_cpp.c:106:17
> #4 in main at soltools/cpp/_cpp.c:60:5
Change-Id: Icbe1c105fbd0ff634f3e2966c27af1b89398be13
Reviewed-on: https://gerrit.libreoffice.org/81187
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
To complete this:
https://gerrit.libreoffice.org/#/c/78312/
This is a massive replace for lines ending with
".." instead of "..."
It passed "make check" on Linux.
Change-Id: I07fa7b2e30ba9ea17a1f9a5e21c57216ba958efe
Reviewed-on: https://gerrit.libreoffice.org/78356
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
It also affects gcc 8.3
Change-Id: I896e84d5e1e96abfe81294e921cfcc060e44fb6f
Reviewed-on: https://gerrit.libreoffice.org/71474
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
V522 There might be dereferencing of a potential null pointer.
Change-Id: Ie617b41a8f8d334022cf5313b242a236baedba48
Reviewed-on: https://gerrit.libreoffice.org/70017
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
V575 The potential null pointer is passed into 'foo' function
Add asserts to those cases that are related to OOM cases. There's
nothing to be done if the assertions fail anyway.
Change-Id: I92ac95d44f512aa1948b1552b0e1f6da695a9f92
Reviewed-on: https://gerrit.libreoffice.org/70008
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
largely based on the relevant portion of the unusedfields loplugin, but
adapted for local vars
Change-Id: Ic522a941573940e8f75c88f90ba5f37508ca49b1
Reviewed-on: https://gerrit.libreoffice.org/66835
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which led to a whole bunch of dead code
Change-Id: If138a05cf7f09b3020e27489b90c32776b859bcf
Reviewed-on: https://gerrit.libreoffice.org/63751
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
After 09841225fc "soltools: fix
-Werror=format-overflow" changed the sprintf into an snprintf, at least the
Fedora 29 "gcc (GCC) 8.2.1 20181011 (Red Hat 8.2.1-4)" now complains about
> [C ] soltools/mkdepend/include.c
> soltools/mkdepend/include.c: In function ‘remove_dotdot.constprop’:
> soltools/mkdepend/include.c:246:42: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
> int n = snprintf(buf, BUFSIZ, "%s%s%s", dir, *dir ? "/" : "", component);
> ^
> soltools/mkdepend/include.c:246:13: note: ‘snprintf’ output 1 or more bytes (assuming 8193) into a destination of size 8192
> int n = snprintf(buf, BUFSIZ, "%s%s%s", dir, *dir ? "/" : "", component);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This all looks not very helpful, lets limit the silencing to just GCC 8.2 (in
the hopes that later versions of GCC won't emit that warning any more, anyway).
Change-Id: I006964e4f32bbb52b6b90288e2d623797b8d38ea
Reviewed-on: https://gerrit.libreoffice.org/63068
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
error: ‘sprintf’ may write a terminating nul past the end of the destination
(Why does GCC8 complain about this now and not before?)
Change-Id: I62cd9dec02d313b5aff1afc4cadf38ca1909ffb1
Reviewed-on: https://gerrit.libreoffice.org/61381
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
... "‘strncpy’ output truncated before terminating nul copying as many bytes
from a string as its length", as reported at
<https://lists.freedesktop.org/archives/libreoffice/2018-October/081109.html>
"LO build fails -Werror=stringop-truncation in _lex.c". Not adding the
terminating NUL appears to be intentional here, as the s->inp buffer is
terminated (through s->inl) with EOB bytes after the if/else blocks.
Change-Id: I5a8559e620b7e34ee27cbcd0f836432deb8cba90
Reviewed-on: https://gerrit.libreoffice.org/61355
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
