Re: [lmi] boost::filesystem oddity

[Greg Chicares]

On 2006-1-18 1:57 UTC, Vadim Zeitlin wrote:
> On Sun, 15 Jan 2006 11:46:15 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--Here's something that puzzles me. I think this code should run
> GC> without throwing any exception. But I can't get it to work that way
> GC> on msw when the boost filesystem library is built as a dll.
[...]
> GC>         boost::filesystem::path::default_name_check
> GC>             (boost::filesystem::windows_name
> GC>             );
> GC>         boost::filesystem::path p0("C:/AUTOEXEC.BAT");
> GC> 
> GC> I get
> GC>   boost::filesystem::path: invalid name "C:" in path: "C:/AUTOEXEC.BAT"
> GC> which seems unexpected.
> 
>  I get exactly the same when using boost-filesystem-mgw.dll. I also get the
> same result with cygwin FWIW.
> 
> GC> I've found a way to make code like this work in lmi, but I'd really
> GC> like to understand the problem that I appear to have fixed.
> GC> 
> GC> For the record, here's a problem report that I posted:
> GC>   http://sourceforge.net/mailarchive/message.php?msg_id=14476898

...to which the maintainer replied much as you do here:

>  Concerning the very first paragraph of this mail: I am not at all
> surprized that comparing the function pointers doesn't work. In Win32 PE
> (portable executable) file format, the calls to DLL functions are indirect
> as this allows the loader to adjust the real address of the function (which
> may differ from execution to execution) only in one place instead of
> scanning the entire program.

Maybe I would have concluded that if it were anyone else's work. But this
is a boost library, designed to be proposed as an addition to the Standard,
and reviewed over several years by eminent experts. So I figured that if I
couldn't get it to work as an msw dll, in a trivial and obvious testcase,
then...well, I must have made a mistake somewhere.

But the API really is broken:

>  And so the implementation of path::m_path_append() in
> path_posix_window.cpp doesn't risk to work under Windows.

Yes. Function pointers just can't be passed blithely across dll boundaries.

For name-check defined functions in the boost library, they should have
used either an internal function returning a function pointer, or an enum.

It turns out that this has been reported already, most recently last month:
  http://lists.boost.org/boost-users/2005/12/15592.php

> But wait, there
> is more: AFAICS it's just plainly buggy as well as using windows_name in
> the way you do above can't work at all. If you look at the code you can see
> that the checker is compared to no_check and native only, so passing it
> windows_name can never work -- yet results in no compile warnings.

It turns out that this was reported on 2004-03-19:
  http://aspn.activestate.com/ASPN/Mail/Message/boost/2029651
yet the defect seems to persist in the boost-1.33.0
  
http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/filesystem/src/Attic/path_posix_windows.cpp?rev=1.20&only_with_tag=RC_1_33_0&view=markup
release candidate of 2005-07-16. (After that, it looks like they
refactored it extensively.)

>  If we still have a real problem with this, I could spend more time on it,
> of course.

Thanks, but I've already worked around it (ChangeLog for 20060115T1243Z)
by setting the default policy in the dll.