-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add RFC95 text: Use standard C/C++ integer types #8399
Conversation
fb614a7
to
23dc139
Compare
1) Proceed with them, keep GDAL 3.8 as version number. External code will have | ||
to use #ifdef if support for GDAL < 3.8 and >= 3.8 is needed. | ||
|
||
2) Same as 1), but bump GDAL version number to 4.0. Cleaner way |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think doing this as a 4.0 change makes the most sense since it is a breaking change requiring changes in upstream codebases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@snowman2 @rouault I mentioned implications for Rasterio and Fiona on gdal-dev and will repeat myself here. I'm not sure what the necessary changes would be for them... they're Cython, not C, and the Cython project feels like conditional compilation directives was a mistake 😂
It's not clear to me that we can do just this https://github.com/PDAL/PDAL/pull/4179/files#diff-22b766759d40394aa74c390f2ff295b1737020f1a824e103238b60efa9e2814fR36 like for PDAL.
Introducing stubs to support type changes would be a drag, hopefully that could be avoided.
Merging as "proposed, but not adopted" |
Partially rendered view here