On Thu, 2018-04-05 at 09:53 +0200, Stephan Bergmann wrote:
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=8bc951daf79
decbd8a599a409c6d33c5456710e0>
"long->sal_Int32 in tools/gen.hxx" changed tools/gen.hxx classes
like Point and Rect from being based on long members to being based
on sal_Int32 members. It was probably a good idea to make the type
of those members platform-independent, so that behavior will not
unnecessarily differ among platforms. Relevant choices for
platform-independent type were apparently sal_Int32 and sal_Int64.
Choosing sal_Int32 seems reasonable, given that this choice
obviously worked well already for all platforms where long is 32 bit
(which includes all variants of Windows, x86 and x86-64). Or did it?
Other fallout from that "long->sal_Int32 in tools/gen.hxx" commit
are <https://cgit.freedesktop.org/libreoffice/core/commit/?id=9762c9a
b98a2b9ea86186a6da7b77031f1416bed>
"ofz: lots of integer overflow noise"
FWIW, there were 28 new Integer overflow findings in oss-fuzz in the
last ~24 hours. Looks like having them as 64bit (by pure historical
accident) was really helpful in sanitizing external data. Lots of the
overflows happen far away from where the data is read in, after some
scaling, rotating and other tweaking, so I don't see a general route to
limiting them at input.
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.