[gdal-dev] Assert due to stack corruption in FlatGeoBuf export

[Ray at Daylon]

This may already be known, but the use of std::string in CPLString
can also cause problems e.g. building a program with a version of
a C++ stdlib that differs from the one that a prebuilt GDAL DLL
used. Visual Studio e.g. has afaik a 48-byte std::string in MSVC 2010
vs. 40 bytes in MSVC 2022. It's obvious in hindsight, but it's easy
to get lulled into using an old DLL for a long time not realizing
it too must be recompiled.

Ray


On 2/25/2024 8:46 PM, Simon Eves via gdal-dev wrote:
> As we're not ready to upgrade Arrow just yet, I also did the namespace 
> change as a pre-build code patch on the regular 3.7.3 bundle.
> 
> Apologies to Bjorn and anyone else on that team for any inference that 
> this was a flatbuffers bug. Not my intention. Glad we worked it out.
> 
> Simon
> 
> On Sun, Feb 25, 2024 at 5:52 PM Even Rouault <even.rouault at spatialys.com 
> <mailto:even.rouault at spatialys.com>> wrote:
> 
> 
>      >
>      > OK, so I guess we might be able to avoid it by upgrading Arrow, as
>      > long as that doesn't break something else. I guess you need to do
>      > the custom namespace thing too, though.
>     (ab)use of preprocessor functionality makes it easy:
>     https://github.com/OSGeo/gdal/pull/9313
>     <https://github.com/OSGeo/gdal/pull/9313> ...
>      >
>      > I hate computers.
> 
>     :-) :-)
> 
> 
>     -- 
>     http://www.spatialys.com <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