Re: [Boost-users] strange filesystem dll behaviour

From: Paul (elegant_dice_at_[hidden])
Date: 2005-08-21 03:42:13

Hi,

I thought you said this code was going away in "the next version" (see 
your response at the bottom).  The code is still the same as in 1.32, 
and AFAIK, it will still suffer the same problem that I reported months ago.

Namely, the test (checker == native) is NOT valid in a win32 DLL 
context, because the function pointers will have different addresses 
when they come from different DLL contexts!

thanks
Paul

Beman Dawes wrote:
> 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
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>