Re: [Boost-users] strange filesystem dll behaviour

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-01-21 10:18:02

At 01:12 AM 1/20/2005, Paul wrote:
 >I looked deeper into the problem, and hacked up boost a little to find
 >out that the problem is the following check:
 >
 >       if ( (checker == no_check || checker == native) && src.size() >= 2 
)
 >at path_posix_windows.cpp:243
 >
 >specifically checker==native.
 >
 >I had constructed path with boost::filesystem::native, but when I hacked
 >it up to do the following:
 >
 >#     ifdef BOOST_WINDOWS
 >       std::stringstream ss; ss << "checker=" <<
 >reinterpret_cast<unsigned long>(checker) << std::endl
 >	      << "native=" << reinterpret_cast<unsigned long>(native) <<
 >std::endl;
 >       boost::throw_exception( filesystem_error(
 >	"boost::filesystem::path",
 >	ss.str() ));
 >
 >       if ( (checker == no_check || checker == native) && src.size() >= 2 
)
 >
 >
 >I got the following results from calling the line:
 >boost::filesystem::path p(s,boost::filesystem::native);
 >
 >
 >linking to libboost_filesystem-mgw-d-1_32.lib:
 >checker=4201048   native=4201048
 >
 >linking to boost_filesystem-mgw-d-1_32.dll:
 >checker=4263776   native=1649966248
 >
 >
 >so, it appears that testing the checker using the address of a function
 >is unreliable in a DLL context?  Have I compiled my program/library
 >incorrectly?  I am not too familiar with DLL details etc, can someone
 >else please shed some light on this?

I'm not a DLL expert either, but it certainly looks like there is some 
problem with address of functions across DLL boundaries.

This code will be going away in the next version of the library, so I'm not 
sure if it is worth putting a lot of effort into fixing it. But I'll try to 
reproduce the problem here. If it does reproduce, it shouldn't be too hard 
to come up with an interim fix.

Thanks for the report,

--Beman