CPLString methods produce objects which crosses library boundaries

[dron]

Printf() methods in CPLString class return references to string object, allocated inside the GDAL DLL. This results in number of problems if the CPLString object was initially allocated in the user program and one of these methods was used after that.

The problem is being highlighted by MSVC compiler when the GDAL DLL has been built using /MD switch and user space program has been built with /MDd switch (the later option forces using debug version of runtime libraries and replaces memory allocation routines). The following sample code throws exception:

#include <cpl_string.h>

int main()
{
    CPLString str;

    
    str.Printf("Bug is here %d!\n", 10);

    printf("%s\n", str.c_str());

    return 0;
}

[Mateusz Łoskot]

The problem is cause by crossing modules (.exe/.dll) boundaries during allocation and assignment new value to the str object (assignment to *this in CPLString::vPrintf() function).

[warmerdam]

The most obvious solution (in my mind) to this problem is to discourage use of CPLString in application code. I have already avoided using CPLString in the GDAL API because of issues such as this.

Or is there a better approach?

[Mateusz Łoskot]

Another possible solution is to redeclare Printf() and vPrintf() function members as static functions in CPLString class.

Then usage will look as follows:

#include <cpl_string.h>
int main()
{
    CPLString str;
    CPLString::Printf(str, "Test %d", 10);

    return 0;
}

[warmerdam]

I don't find that an acceptable solution due to the messiness of the syntax.

In fact, I generally don't feel this is a bug and as such I'm closing it.

Applications wanting to use a different runtime/heap than the GDAL DLL need to be very careful about allocations and this is just one of many things that can go wrong.

[Even Rouault]

In 40242:

nmake.opt: use /MDd for OPTFLAGS for DEBUG=1 builds (fixes #7059, fixes #6384, fixes #4291, fixes #3346, fixes #1647, fixes #540)