<div dir="ltr"><div>It sounds reasonable to me. I agree with Kurt answers (about Q3 I have not opinion).</div><div>(btw, I have no vote)<br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Javier.</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 15 Sept 2023 at 18:21, Kurt Schwehr <<a href="mailto:schwehr@gmail.com">schwehr@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">+1 Yes please!!<br><div><br></div><div>Thoughts:</div><div>- I've battled with the types so many times over the years. The pain caused by a switch will be well worth it</div><div>- Q1: I'm for going to GDAL 4.0.<br></div><div>- 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</div><div>- 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.</div><div><br></div><div>Short term pain, but long term big gains in readability for people new to GDAL / stability / maintainability / ability to cross compile.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 15, 2023 at 2:24 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I've submitted an initial version of RFC95: Use standard C/C++ integer types<br>
<br>
     <a href="https://github.com/OSGeo/gdal/pull/8399" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/pull/8399</a><br>
<br>
It has important implications on backward compatibility of C and C++ <br>
API. The "questions to be answer" paragraph need to be answered.<br>
<br>
Even<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>