Re: [lmi] Path validation in boost and std::fs

[Vadim Zeitlin]

On Sat, 17 Mar 2018 14:43:32 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-03-16 18:49, Vadim Zeitlin wrote:
GC> > 
GC> >  I'd like to return to this topic to discuss how to handle an important
GC> > difference between Boost.Filesystem and std::filesystem libraries. The
GC> > former one has the concept of "checkers", which are used whenever paths 
are
GC> > constructed to verify their validity, while the latter one seems to take a
GC> > much more relaxed, Unix-like, approach and doesn't impose any restrictions
GC> > at all on the path components.
GC> 
GC> Do you know why they removed it? Using 'name_check' as a search term,
GC> I don't find any discussion on lists.boost.org . Just curious.

 No, I don't know for sure, all I know is that it happened a long time ago
(earlier than 2010, I think). Whatever the reason was, I can't say I regret
it however.

GC> >  Moreover, I'm not really sure how much value do these checks represent.
GC> > Any attempt to actually use a path with invalid characters in it would 
fail
GC> > anyhow under systems imposing such restrictions (i.e. MSW), so what do we
GC> > gain from checking for them preventively?
GC> 
GC> It seems good to prevent users from making mistakes like:
GC>   File | Save as
GC>     `XYZ' Corp.[#2 of 3] (managers and/or professionals?) <New York only>.
GC>   OK

 I'm almost sure that you wouldn't be able to enter such path in the MSW
"Save file" dialog. In fact, scratch "almost": I've just tested it and,
indeed, the dialog does its own validation.

 Of course, it's still possible that the path comes from somewhere else,
e.g. command line maybe, but it seems rather unlikely.

GC> I guess that was boost's original rationale for the name_check
GC> mechanism. If paths are checked preemptively, then in principle we
GC> can trap insane names up front, and report them as elaborately
GC> as we like...e.g., instead of letting a downstream library issue
GC> a cryptic diagnostic such as "xml: parse error", or, worse, a
GC> screenful of XSL-FO diagnostics when a name is acceptable to msw
GC> but not to java.

 I didn't test what actually happens if an invalid file name is passed to
any of the functions working with files in xmlwrapp, but if the error
message is insufficiently clear, the problem should really be fixed at this
level IMO.

GC> >  There is also a compromise solution of only performing these checks in
GC> > validate_path() itself. This would then allow to do such checks when we
GC> > really need them, while still allowing us to use just fs::path directly
GC> > elsewhere.
GC> 
GC> Yes, that's perfect. I think the platform-specific rules boost
GC> used are simple enough to clone.

 OK, thanks, I'll do this then.

GC> We use validate_path() rarely--AFAICS, only for directories and
GC> files controlled by configurable_settings or global_settings,

 Yes, exactly.

 Thanks again for your answer,
VZ