Would it help if, for a future release, we tried to replicate all of the API entry points that take std::string& to have another version that takes const char*, so that apps can use either one (in particular, so that platform/app combinations that find std::string dangerous, which obviously doesn't include the ones I use, can use the char* ones?).
On Mon, Apr 8, 2013 at 9:14 AM, Brecht Van Lommel < [email protected]> wrote: > Hi Michel, > > We've had similar issues with Blender, and I don't have a good > solution for it either. There's a lot of confusing information about > this online, my understanding is that to avoid issues you must: > > * Ensure all the compiler flags match for the application and all > libraries. > * Build with /MD instead of /MT when using a DLL. Otherwise the DLL > and main application will not use the same heap. /MT does work ok with > a static OIIO library. > > It would be nice if the OIIO (and OSL) API would not use these STL > data structures, but this of course involves major API compatibility > breakage. So I'm not sure how practical this is. > > Brecht. > > On Mon, Apr 8, 2013 at 4:51 PM, Michel Lerenard > <[email protected]> wrote: > > Hi everybody, > > > > we've been struggling for a few days hunting a weird bug in > > ImageInput::create, and the search raised one major concern about the > use of > > std::string in the API. > > I don't know if the issue has been discussed before (in a sense, I hope > > not). > > > > We've had a crash when trying to open a specific JPEG file. To understand > > its cause we built OIIO in debug, to find that the crash occured in the > > geterror() function. Apparently it crashed in the destruction of the > > std::string that is used in ImageInput::create because it's been > > overwritten. > > Recompiling with more debug flags we found that strangely the string is > > already in a bad state before opening the file: we crashed in the boost > > function that extracts the extension of the file. (called from the line > > "std::string format = Filesystem::extension (filename)" in > > ImageInput::create). > > Which is quite weird because it does not relate very well with the crash > we > > had at the beginning, which was linked to the data in the file. And it > now > > crashes on every single file we try to open. > > > > Trying to dig deeper we hit a bunch of issues, mainly related to > std::string > > and the way it's implemented. > > > > Is there a reason for using "std::string" instead of a simple "char*" > (even > > const) in all interface functions ? As far as we're concerned, it's heavy > > and raises many compatibility issues especially under windows ( libraries > > versions, debug/non debug MT option, etc...). So far we have failed to > build > > a full debug version of an application using OIIO that does not crash at > > startup. Either we can't debug because libraries are in release, either > we > > crash in mainCRTStartup. > > > > Our debug session uses the trunk of OIIO and boost 1.44 version. > > > > We used boost 1.44 because of this bug > > https://svn.boost.org/trac/boost/ticket/6320, which seems to have > appeared > > in 1.48 and was fixed only on boost trunk at this time. At first we used > the > > 1.49 version then tried the 1.53 and finally the 1.44. Going back to the > > 1.44 did change things a bit: with OIIO in release with debug info, no > > crash. But OIIO won't load any image. > > > > ------------------------------ > > Michel > > Isotropix SAS > > > > _______________________________________________ > > Oiio-dev mailing list > > [email protected] > > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
