... "‘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>
...showing that tottok and tokkind are actually unused
Change-Id: Ic70f4f1fd7b585b00e98b538d116599e395a43b9
Reviewed-on: https://gerrit.libreoffice.org/60536
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
under --with-lang=ALL it had started to crash during e.g.
> LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}".../instdir/program:.../instdir/program" .../workdir/LinkTarget/Executable/cpp -+ -P -DWITH_POSTGRESQL_SDBC -DWITH_FIREBIRD_SDBC -DWITHOUT_EXTENSION_MEDIAWIKI -DWITHOUT_SCRIPTING_BEANSHELL -DWITHOUT_SCRIPTING_JAVASCRIPT -DWITH_HELPPACK_INTEGRATION -DWITH_EXTENSION_INTEGRATION -DENABLE_EXTENSION_UPDATE -DX86_64 -DLINUX -D_PTHREADS -DUNIX -DUNX -DCOMID=gcc3 -D_gcc3 -DWITH_LPSOLVER -I.../scp2/inc -I.../workdir -I.../config_host -I.../workdir/CustomTarget/scp2/macros -I.../workdir/ScpTemplateTarget/scp2/source/templates .../scp2/source/calc/file_calc.scp > .../workdir/ScpPreprocessTarget/scp2/source/calc/file_calc.pre
because of
> Syscall param read(buf) points to unaddressable byte(s)
> at 0x4F31A80: __read_nocancel (syscall-template.S:84)
> by 0x404F98: fillbuf (_lex.c:631)
> by 0x404CCF: gettokens (_lex.c:479)
> by 0x400F0A: process (_cpp.c:77)
> by 0x400E80: main (_cpp.c:60)
> Address 0x5278494 is 0 bytes after a block of size 32,772 alloc'd
> at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
> by 0x402034: domalloc (_cpp.c:321)
> by 0x40554F: setsource (_lex.c:679)
> by 0x403E38: doinclude (_include.c:130)
> by 0x401F9D: control (_cpp.c:297)
> by 0x401002: process (_cpp.c:101)
> by 0x400E80: main (_cpp.c:60)
There appears to be no other check that fillbuf doesn't overflow the Source's
input buffer, other than gettokens checking that the buffer isn't more than
three quarters full ("if (ip >= s->inb + (3 * INS / 4)) ..."). That smells like
cpp assumes input lines to be shorter than some maximum number of characters
(like the C99 standard setting a minimum limit of "4095 characters in logical
source lines"), and
> #define README_TXT_ALL_LANG(key, name, ext) \
> key (af) = READMETXTFILENAME(name,_af,ext); \
> Name (am) = CONFIGLANGFILENAME(name,am,ext); \
> Name (ar) = CONFIGLANGFILENAME(name,ar,ext); \
[...]
> Name (zh-CN) = CONFIGLANGFILENAME(name,zh-CN,ext); \
> Name (zh-TW) = CONFIGLANGFILENAME(name,zh-TW,ext); \
> key (zu) = READMETXTFILENAME(name,_zu,ext)
in workdir/CustomTarget/scp2/macros/langmacros.inc (which appears to be the
culprit here) exceeding that limit under --with-lang=ALL.
So just bump the input buffer size.
Change-Id: I5d863050fb772dc7e691a604009ff8702dc718e3
The types 'long' and 'unsigned long' are different sizes on different
platforms, making them wholy unsuitable for portable code.
And when I mean different sizes, I mean 64bit Linux and 64bit Windows
have different bit sizes.
Change-Id: Id4d8cd709bf71a3f85ed6515fae2b0a21ae8c25d
Reviewed-on: https://gerrit.libreoffice.org/41130
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Translates leftovers found using a custom regex and manually checking
the rest of the affected file.
Additionally:
- Translation of someone's attempts at Spanish in the .java file
Change-Id: Ie3a761bc1a8e302247d5dd6e93a6bc4cb3e85a9f
Reviewed-on: https://gerrit.libreoffice.org/39609
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
Whatever those _POSIX_ for _MSV_VER were supposed to be good for (have been in
there at least ever since 4f4b74153d "Moved cpp
from cpp to soltools"), but cause -Wunused-macros at least when building with
clang-cl.
Change-Id: I356bf663cd1e86298ba72a179f46bb9d0c10016b
stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
I don´t know why it doesn´t work anymore, but the fix is trivial
may be related of using the Windows 8.0 SDK.
Change-Id: Ia09109b53d4f022a732ea781c98ddd4eb0c721d9
The following tools are considered to be obsolete and are discontinued:
ldump, giparser, testhxx and support.
Change-Id: I70813c046edb30546463cda9eb8a1b96c3e840a3
Noel Grandin