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

[Daniel Baston]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20171228/a55d39fc/attachment.html>