[postgis-devel] size_t: width and signedness of counters

[Darafei "Komяpa" Praliaskouski]

Hi,

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:
https://github.com/postgis/postgis/pull/176#discussion_r158592196

I've brought that habit from maps.me development team. Maps.me is
cross-compiled for a set of architectures of modern Android devices (from
MIPS through ARMs to x86_64).

size_t is convenient as counter/index variable because of:

 - it's unsigned. Any -1 becomes large enough to trigger segfault, address
sanitizer and any kind of static code validators.

 - 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).

 - 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.

 - 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.
:)

If you think this change causes problems, let me know.

Could it be that we want this everywhere? :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20171227/f8b26b5d/attachment.html>