ocumented in https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation Change-Id: Id166f425238e50d4131f72bcfd22b5268dea0c3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163915 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Age	Commit message (Collapse)	Author
2016-05-17	odk: add missing modelines	Miklos Vajna
	Change-Id: I0bd2d761b5a75681c8c3e53664084dd3b8176107 Reviewed-on: https://gerrit.libreoffice.org/25051 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2023-01-27	Remove support for AIX	Stephan Bergmann
	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>
2022-04-11	-Werror,-Wstrict-prototypes (clang-cl)	Stephan Bergmann
	Change-Id: I72e35f51eb607662608ccaf944bec64ed422cef4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132835 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-17	cid#706181 Use of untrusted string value	Caolán McNamara
	use an annotation here and add one to the windows equivalent Change-Id: Ife54949c2e89ae606d7931be82807db4bbb132dc Reviewed-on: https://gerrit.libreoffice.org/83024 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-03-31	tdf#120703 PVS: Silence V575 warnings	Mike Kaganski
	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>
2018-09-24	loplugin:external (clang-cl)	Stephan Bergmann
	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>
2018-09-17	New loplugin:external	Stephan Bergmann
	...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>
2018-02-01	odk: MSVC: pragma warning: make more specific, remove obsolete	Mike Kaganski
	Change-Id: Ie5957edb3954507505a7df9fad9f8da6b87b09d0 Reviewed-on: https://gerrit.libreoffice.org/49038 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>