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

[Paul Norman]

On 12/27/2017 8:37 AM, Darafei "Komяpa" Praliaskouski wrote:
> 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 <http://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? :)
>


I've been in the habit of using size_t from C++, where it's what all the 
STL size-related operators use, and thus what you get when you use auto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20171230/9f0584f8/attachment.html>