<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>I could live with a uint32-t standard.</div><div>P</div><div><br>On Dec 28, 2017, at 6:18 AM, Daniel Baston <<a href="mailto:dbaston@gmail.com">dbaston@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hi Darafei,<div><br></div><div>Thanks for raising the issue. The PostGIS code is currently using a mix of int types and I think some standardization would be useful (if nothing else, it would remove a heap of warnings from my editor.)</div><div><br></div><div>In the PostGIS geometry format, "ngeoms" and "npoints" are both defined as an unsigned 32-bit integer, regardless of platform. Given this, I think it's most straightforward to use a uint32_t to iterate over these quantities. I understand that the size of the platform-dependent size_t should always be >= uint32_t, but I can't see a reason to prefer it. But maybe I'm missing something with your statement about pointer arithmetic?</div><div><br></div><div>Dan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 27, 2017 at 11:37 AM, Darafei "Komяpa" Praliaskouski <span dir="ltr"><<a href="mailto:me@komzpa.net" target="_blank">me@komzpa.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>On my weighted median PR Dan Baston asked why do I use size_t as loop/array index even though PostGIS point array size is limited to 32-bit:</div><div><a href="https://github.com/postgis/postgis/pull/176#discussion_r158592196" target="_blank">https://github.com/postgis/<wbr>postgis/pull/176#discussion_<wbr>r158592196</a> <br></div><div><br></div><div>I've brought that habit from <a href="http://maps.me" target="_blank">maps.me</a> development team. <a href="http://Maps.me">Maps.me</a> is cross-compiled for a set of architectures of modern Android devices (from MIPS through ARMs to x86_64).</div><div><br></div><div>size_t is convenient as counter/index variable because of:</div><div><br></div><div> - it's unsigned. Any -1 becomes large enough to trigger segfault, address sanitizer and any kind of static code validators.</div><div><br></div><div> - it's type returned by sizeof(). You can't safely have an array larger than largest possible sizeof(array) of your compiler. (By standard you may be limited to 65536 elements - I don't expect PostGIS to be working in 16 bit systems, and uint32_t as counter won't help there to store longer arrays anyway).<br><br></div><div> - it's aligned with system architecture, being 32bit on 32bit systems and 64bit on 64-bit systems. Adding/subtracting it from pointers don't normally require compiler to perform implicit type casting. This is not required by standard but it is this way in practice.</div><div><br></div><div> - after some time of adopting such arrangement you see size_t variable and immediately know it's a positive counter that might be used as array index. :)<br><br>If you think this change causes problems, let me know.<br><br>Could it be that we want this everywhere? :)</div></div>
<br>______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a><br></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>postgis-devel mailing list</span><br><span><a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a></span><br><span><a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></span></div></blockquote></body></html>