Re: long->sal_Int32 in tools/gen.hxx

[Noel Grandin]

So I see we're going to revert my "long->salInt32" commit - which I'm fine
with, it's better that we get our testing tools back on a even keel.

But it is as well to acknowledge that we are only hiding these flaws, not
solving them - all of the overflow and other integer issues we saw here,
exist currently on our windows platform, and will need to be solved at some
point.

Is there a path forward for this? I can try again, and fix the ASAN issues
before I push, but I can't easily run the kinds of tools Caolan is using.
​
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: long->sal_Int32 in tools/gen.hxx

[Stephan Bergmann]

On 05/04/18 09:53, Stephan Bergmann wrote:
I propose that we revisit the "long->sal_Int32 in tools/gen.hxx" commit 
and change to sal_Int64 instead:


doing that now as  
"sal_Int32->sal_Int64 in tools/gen.hxx"

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: long->sal_Int32 in tools/gen.hxx

[Caolán McNamara]

On Thu, 2018-04-05 at 09:53 +0200, Stephan Bergmann wrote:
>  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  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.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice