RE: [Boost-users] strange filesystem dll behaviour

From: Delfin Rojas (drojas_at_[hidden])
Date: 2005-01-21 12:38:48

I just wanted to say that I have seen this problem too. I thought it was
something I was doing wrong. Normally, if I re-compile the dll it goes
away...

-delfin

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Beman Dawes
> Sent: Friday, January 21, 2005 7:18 AM
> To: boost-users_at_[hidden]; boost-users_at_[hidden]
> Subject: Re: [Boost-users] strange filesystem dll behaviour
> 
> 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