[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] boost::filesystem anomaly?

From: Vadim Zeitlin
Subject: Re: [lmi] boost::filesystem anomaly?
Date: Sat, 11 Jun 2016 17:48:48 +0200

On Sat, 11 Jun 2016 12:23:29 +0000 Greg Chicares <address@hidden> wrote:

GC> What should this print under msw?
GC>   std::string s("C:/opt/lmi/bin");
GC>   fs::path g(s, fs::no_check);
GC>   std::cout << g.string() << std::endl;
GC> I think it should print
GC>   C:/opt/lmi/bin <-- expected
GC> and not
GC>   C:opt/lmi/bin <-- unexpected: first slash deleted

 Yes, this is, of course, what I'd expect too.

GC> With the first patch[0] below, I run lmi and get:
GC>   g is 'C:opt/lmi/bin'
GC>   g is 'C:opt/lmi/bin'
GC> in two successive messageboxes. Note that the third character ("/")
GC> of the original string is missing. (I think that's wrong.)

 It is, but it took me some time to understand the reason for it. The
trouble is that there are 2 copies of boost_filesystem library in the
lmi_wx executable. Because of this, fs::no_check used above is *not* the
same no_check object that the no_check defined in path_posix_windows.cpp
that the code in path::m_path_append() compares the checker with, hence the
check for Windows paths is completely skipped, resulting in the bug.

 I'm not sure how exactly do we end up with 2 copies of the filesystem
library, but this is almost certainly what happens and I'll try to debug it
later when I have more time (unfortunately I'm not sure if I can manage to
do it today) and I wanted to already post this reply to make sure you know
that this is indeed "just" a bug which simply needs to be fixed, although
probably at makefile, rather than at the code, level.

 BTW, if we updated to a newer (and more std::filesystem-compatible)
version of the Boost.Filesystem library which doesn't have the concept of
"checkers" any more, we wouldn't have to spend time on dealing with this

 Anyhow, I'll return to this soon, unless you tell me to not do it, and
will post a fix as soon as I have one.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]