<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Thu, Jun 4, 2015 at 1:32 AM, Alvaro
Herrera<span dir="ltr"><<a href="mailto:alvherre@2ndquadrant.com"
target="_blank">alvherre@2ndquadrant.com</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px#ccc solid;padding-left:1ex"><span class="">Andreas Seltenreich wrote:<br /> > Tom Lane <<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>writes:<br /> ><br /> > > Andreas Seltenreich <<a
href="mailto:andreas.seltenreich@credativ.de">andreas.seltenreich@credativ.de</a>>writes:<br /> > >> The
scaryone is due to an integer overflow the attached patch also<br /> > >> fixes.<br /> > ><br /> >
>s/int/Size/ doesn't fix anything on 32-bit machines.<br /> ><br /> > Well, it changes the signedness of the
computationon 32-bit, and in<br /> > combination with the fact that "len" is always smaller than 2^32, but<br />
>may exceed 2^31-1, the change avoids the dependency on the undefined<br /> > behavior of signed integer
overflowsin C on 32-bit as well.<br /><br /></span>Why not just use an unsigned 64 bit variable? Also, perhaps<br />
palloc_huge()avoids the whole problem in the first place ... though it<br /> might only move the issue around, if you
cannotship the longer-than-1GB<br /> resulting escaped value. (Of course, if you try to allocate 2 GB in a<br /> 32
bitmachine, you're going to be having quite some fun ...)<span class="HOEnZb"></span><br /></blockquote></div><br
/></div><divclass="gmail_extra">Pure nitpicking: there is no palloc_huge, only repalloc_huge. Though we could have
one.<br/>-- <br /><div class="gmail_signature">Michael<br /></div></div></div>
