I would strongly lean towards std::string if possible. I'm not sure how a realloc on the heap is any less safe than a std::string and strings can have memory reserved at construction time (or ::reserve()). Or in crazy cases, a custom allocator can be used that has a preallocated pool of memory available for when the system is OOM.
A related question... any idea what the '0' char is for? It looks like you introduced the zero char after \n in https://trac.osgeo.org/gdal/changeset/14601 and I don't see '0' in https://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_error.cpp?annotate=blame&rev=14600 On Tue, May 16, 2017 at 11:01 AM, Even Rouault <even.roua...@spatialys.com> wrote: > On mardi 16 mai 2017 10:26:09 CEST Kurt Schwehr wrote: > > > I now know this is referred to as the "struct hack." > > > > > > This really is undefined behavior in the C++11 standard... > > > > Well, I don't think the hack is really needed and char szLastErrorMsg[] > could be replaces by a char* pszLastErrorMsg that would be malloc'ated. > > The current situation comes from the fact that originally no custom free > function could be associated with a TLS member, but now that we have a > > CPLSetTLSWithFreeFunc() we could use it to free the pszLastErrorMsg member > before freeing the context. > > > > (or use std::string if you prefer, but this code portion can be run under > very low memory conditions, so great care is needed) > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com > -- -- http://schwehr.org
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev