<div dir="ltr">I see that trunk and 2.5 mostly already had fixes in place for this and have brought them to 2.4 as well.<div><br></div><div>P.</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 31, 2018 at 3:15 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On mercredi 31 octobre 2018 14:25:34 CET Paul Ramsey wrote:<br>
> Looks like it was Andres, about two months ago, during the switch to<br>
> "modern" C99<br>
> <br>
> <a href="https://github.com/postgres/postgres/blame/696b0c5fd0a8765fe6dfd075a30be06b4" rel="noreferrer" target="_blank">https://github.com/postgres/postgres/blame/696b0c5fd0a8765fe6dfd075a30be06b4</a><br>
> 48fd615/<a href="http://configure.in#L488" rel="noreferrer" target="_blank">configure.in#L488</a><br>
> <br>
> Wikipedia commentary :)<br>
> <br>
> <a href="https://en.wikipedia.org/wiki/Variable-length_array#C99" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Variable-length_array#C99</a><br>
<br>
Beyond Linus' arguments about speed and code size which aren't really relevant <br>
here unless you're counting the number of CPU cycles, looking a bit at the <br>
code for the below cases, the use of VLAs seems inappropriate as the size <br>
argument could be pretty huge, being the number of points of the input <br>
geometries. Surprising that nobody hasn't come up yet with gigantic geometries <br>
that would blow up the stack of the process ( typically the default stack size <br>
of a Linux process is 8 MB, so a geometry with ~ 262 000 points would blow the <br>
stack). I wouldn't call fixing that bikeshedding.<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div>