With GCC 15.2, compiler produces this error message:
[LOC] top level modules: odk
odk/source/unoapploader/unx/unoapploader.c: In function ‘createCommandName’:
odk/source/unoapploader/unx/unoapploader.c:285:13: error: assignment discards
‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
285 | sep = strrchr( prgname, SEPARATOR );
| ^
cc1: all warnings being treated as errors
By defining sep as "const char*" instead of "char*", the problem goes away.
Change-Id: If1d628dba8bb4ec657b916fa61927b250d3039c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202942
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
This patch adds a new Python helper script to generate Addons.xcu for
LibreOffice extensions. The script works like a wizard, and asks user
about the needed details. It provides these options for the application
module context:
1. Writer
2. Spreadsheet
3. Presentation
4. Draw
5. Formula
6. Chart
7. Bibliography
After selection of the module, appropriate Addons.xcu is generated, and
user is asked to choose between 'desktop' or a custom folder to save the
resulting file.
Change-Id: I22a878f0bde19a870674a357d7085ad3c12fc50c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163382
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
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>
...where the default encoding should be the appropriate one for reading the
Runtime.exec output
Change-Id: Ib64bfcbcca985f2de506f8628b506e6dc7bfc035
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107255
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The SDK's <https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/
Transparent_Use_of_Office_UNO_Components> on all platforms included the Windows-
specific unowinreg.dll in generated jars (so that those jars, when distributed
to a Windows environment, would find a LO installation by inspecting the Windows
registry). That unowinreg.dll was originally built as a 32-bit DLL (though when
building a 64-bit Windows LO, it happened to be built as a 64-bit DLL). For
non-Windows LO builds, it could either be built locally with a MinGW toolchain
(--enable-build-unowinreg) or downloaded from dev-www.libreoffice.org.
However, that had various issues:
For one, unowinreg.dll was not necessarily available in a distributed jar as a
64-bit DLL for use with a 64-bit JRE on Windows. (Theoretically, running such a
jar with a 32-bit JRE to access a 64-bit LO installation's URE jars could have
worked. But practically, those URE jars in turn require native DLLs, which
would then not have been available as 32-bit DLLs for use in the 32-bit JRE.)
For another, at least the unowinreg.dll resulting from --enable-build-unowinreg
on Fedora 33 would have had a dependency on libgcc_s_dw2-1.dll that would
generally not have been available in a target Windows environment.
There appears to be no pure Java way to read the Windows registry, but instead
of using a native code DLL for that, it appears to work just as well to call out
to reg.exe and parse its output.
This removes the --enable-build-unowinreg and --with-mingw-cross-compiler
configuration options. (The sole use of the MinGW toolchain in LO was for
building unowinreg.dll.)
Change-Id: I3283ea38c884d3221a205e5ab6ec99a2691ef474
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107140
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
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>
Including:
* expanding STDAPI to its definition (as per
<https://msdn.microsoft.com/library/ms686631(vs.85).aspx> "STDAPI"), to add
__declspec(dllexport) into its middle, in
extensions/source/activex/so_activex.cxx; as discussed in the comments at
<https://gerrit.libreoffice.org/#/c/60691/> "Get rid of Windows .def files in
setup_native, use __declspec(dllexport)", having a function both listed in a
.def file EXPORTS and marking it dllexport is OK, and the latter helps the
heuristics of loplugin:external; however, the relevant functions in
extensions/source/activex/so_activex.cxx probably don't even need to be
exported in the first place?
* follow-up loplugin:salcall in sal/osl/w32/file-impl.hxx
Change-Id: Ida6e17eba19cfa3d7e5c72dda57409005c0a0191
Reviewed-on: https://gerrit.libreoffice.org/60938
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...similar to 28b4f4aeaf "Get rid of Windows .def
files in setup_native, use __declspec(dllexport)". And JNIEXPORT (with which
the listed functions are decorated in odk/source/unowinreg/win/unowinreg.cxx)
already implies __declspec(dllexport).
Change-Id: I45fd1d50cd3b072d124002e469c70eb1d6ed7610
Reviewed-on: https://gerrit.libreoffice.org/60819
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...warning about (for now only) functions and variables with external linkage
that likely don't need it.
The problems with moving entities into unnamed namespacs and breaking ADL
(as alluded to in comments in compilerplugins/clang/external.cxx) are
illustrated by the fact that while
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
returns 1, both moving just the struct S2 into an nunnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
namespace { struct S2: S1 { int f() { return 1; } }; }
int f(S2 s) { return s.f(); }
}
int main() { return f(N::S2()); }
as well as moving just the function f overload into an unnamed namespace,
struct S1 { int f() { return 0; } };
int f(S1 s) { return s.f(); }
namespace N {
struct S2: S1 { int f() { return 1; } };
namespace { int f(S2 s) { return s.f(); } }
}
int main() { return f(N::S2()); }
would each change the program to return 0 instead.
Change-Id: I4d09f7ac5e8f9bcd6e6bde4712608444b642265c
Reviewed-on: https://gerrit.libreoffice.org/60539
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
On Windows, UTF-8 is never current locale encoding; so using 8-bit
strings will always fail for paths containing characters outside
of current codepage.
Also fix leaks caused by failing to release its result: previously
it could return either result of getenv (that shouldn't get freed),
or an allocated string, but never got freed; now the result is
always allocated and properly freed.
Change-Id: I8b255dea20040eec0572de2b34280749fe8f071c
Reviewed-on: https://gerrit.libreoffice.org/42743
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(sal/inc/rtllifecycle.h only hits on Windows as that is the only platform that happens to
actually include it in a C compilation unit, sal/osl/w32/dllentry.c)
Change-Id: I2878b52daf713ea45eaa2968cc5d2686b86abfe6
and
coverity#1326732 Dm: Dubious method used
coverity#1326734 Dm: Dubious method used
coverity#1326735 Dm: Dubious method used
coverity#1326739 Dm: Dubious method used
Change-Id: Id9d39decf7442b503079ebcfe8c881f0f2fe3eb3
Hossein