Page MenuHomePhabricator

[6/N] [libcxx] Handle backslash as path separator on windows
Needs ReviewPublic

Authored by mstorsjo on Tue, Nov 10, 1:35 AM.

Details

Reviewers
amccarth
EricWF
Group Reviewers
Restricted Project

Diff Detail

Event Timeline

mstorsjo created this revision.Tue, Nov 10, 1:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptTue, Nov 10, 1:35 AM
Herald added 1 blocking reviewer(s): Restricted Project. · View Herald Transcript
amccarth added inline comments.Tue, Dec 1, 2:56 PM
libcxx/include/filesystem
1122
  1. It looks like most places are using preferred_separator, so is there a ever case where you'd have slashes instead of backslashes?
  1. If I've read correctly, the Windows version always uses wide characters, so maybe the character literals should be L'/' and L'\\' so that they naturally match the value type of the iterator.
mstorsjo added inline comments.Tue, Dec 1, 11:10 PM
libcxx/include/filesystem
1122
  1. Yes, the thing is that when a user constructs a path from a string that itself contains path separators, forward slashes are always considered a path separator (as platform agnostic separator), and backslashes work as separator too, on windows only. The filesystem::path internal representation of a path keeps them in whatever form they were input, but this modifier converts the path to the preferred (native) form. FWIW this is exactly what MS STL's version of make_preferred() does too.
  2. Sure, that'd work. For these cases, the plain char form doesn't produce any warnings, but I can change it to wide char literals just for clarity.
mstorsjo updated this revision to Diff 308878.Tue, Dec 1, 11:17 PM

Use wide char literals for forward and back slashes within an windows ifdef.

mstorsjo marked an inline comment as done.Tue, Dec 1, 11:17 PM
mstorsjo updated this revision to Diff 308896.Wed, Dec 2, 12:31 AM

Updated to use _VSTD::replace instead of std::replace in the installed header.