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

[Paul Ramsey]

I could live with a uint32-t standard.
P

> On Dec 28, 2017, at 6:18 AM, Daniel Baston <dbaston at gmail.com> wrote:
> 
> Hi Darafei,
> 
> 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.)
> 
> 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?
> 
> Dan
> 
>> On Wed, Dec 27, 2017 at 11:37 AM, Darafei "Komяpa" Praliaskouski <me at komzpa.net> 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 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? :)
>> 
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20171228/bb24b2f3/attachment.html>