[gdal-dev] Call for discussion/review of RFC95: Use standard C/C++ integer types

[Javier Jimenez Shaw]

It sounds reasonable to me. I agree with Kurt answers (about Q3 I have not
opinion).
(btw, I have no vote)
About GDAL 4.0 vs 3.8, I'm fine with 4.0. But I do not know if "users" will
expect a bigger change in functionalities for a mayor release update.

Cheers,
Javier.

PS I always liked those fully defined types (i.e.: uint64_t) It was clear
to me how big that number could be, regardless the compiler and platform.

On Fri, 15 Sept 2023 at 18:21, Kurt Schwehr <schwehr at gmail.com> wrote:

> +1 Yes please!!
>
> Thoughts:
> - I've battled with the types so many times over the years. The pain
> caused by a switch will be well worth it
> - Q1: I'm for going to GDAL 4.0.
> - Q2: Having a GDAL_USE_OLD_INT_TYPES for a while seems like a good idea
> to expose the alias to users of the library
> - Q3: Yes to vsi_l_offset -> uint64_t. I'm 90% for it. For me: Yes offset
> has meaning, but if the type is critical to understanding a function /
> method interface, we should have a comment. Knowing that it's an unsigned
> 64 bit int is usually more important. Would be great if anyone against this
> change could speak up and give some examples.
>
> Short term pain, but long term big gains in readability for people new to
> GDAL / stability / maintainability / ability to cross compile.
>
> On Fri, Sep 15, 2023 at 2:24 AM Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> Hi,
>>
>> I've submitted an initial version of RFC95: Use standard C/C++ integer
>> types
>>
>>      https://github.com/OSGeo/gdal/pull/8399
>>
>> It has important implications on backward compatibility of C and C++
>> API. The "questions to be answer" paragraph need to be answered.
>>
>> Even
>>
>> --
>> http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230916/15a077a7/attachment.htm>