+1 KurtS One minor comment...
I use pfnOpen in a few of my local fuzzers, but I build statically without plugins, so I think my use won't be impacted. But even if I am impacted, that's my problem and not a responsibility of the GDAL project as I'm using internal GDAL details. > Another potential issue is that if external code would directly use the pfnOpen, pfnCreate, pfnCreateCopy, etc. function pointers of a GDALDriver instance, it would see them null before the actual driver is loading, but direct access to those function pointers has never been documented (instead users should use GDALOpen(), GDALCreate(), GDALCreateCopy() etc), and is not expected to be done by code external to libgdal core. On Wed, Nov 15, 2023 at 1:52 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > Motion: adopt RFC 96: Deferred C++ plugin loading > > https://github.com/OSGeo/gdal/pull/8648 > > Pre-rendered view: > > > https://github.com/rouault/gdal/blob/rfc96_text/doc/source/development/rfc/rfc96_deferred_plugin_loading.rst > > > Starting with my +1, > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
