<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 7 Oct 2020 at 16:51, Luboš Luňák <<a href="mailto:l.lunak@collabora.com">l.lunak@collabora.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday 06 of October 2020, Noel Grandin wrote:<br>> Honestly, the only solution I can think of (and one I confidently expect us<br>
> to reject), is that we declare a flag day, and search and replace<br>
> sal_Long/sal_uLong/long/unsigned long with a 64-bit type across the ENTIRE<br>
> code base.<br>
<br>
 Does it really need to be this extensive though? E.g. VCL should be more or <br>
less safe from this, I think trying any drawing with >32bit sizes is simply <br>
not going to work one way or another.<br>
<br></blockquote><div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">We extensively use shared types like tool::Rectangle in sc.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 Also, how realistic of a solution would be to compile with the <br>
undefined-behaviour sanitizer and make it fail on overflows as a way to get a <br>
decent enough coverage of the problematic areas?<br><br></blockquote><div><span class="gmail_default" style="font-family:tahoma,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif">If you can get that working under Windows, sure, that could help.</span></div><div> </div></div></div>