<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">https://github.com/postgis/postgis/pull/176#discussion_r158592196</a> <br></div><div><br></div><div>I've brought that habit from <a href="http://maps.me">maps.me</a> development team. Maps.me 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>