- boost::filesystem::native - 3 Updates
- OT: Github - 2 Updates
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 11 12:58PM +0200 On 11.11.2016 0:47, Christopher J. Pisz wrote: > } > It seems to report the first 3 of the wide string paths are valid. > This set of boost functions are really confusing. This is because of the abused reinterpret_cast: reinterpret_cast<char*>(L"C://PATH") is pretty much equivalent to (Windows is little-endian): "C" and "C" is indeed a valid file name in Windows. Why on earth do you think you can convert wide strings to narrow strings just by casting? Cheers Paavo |
| "Christopher J. Pisz" <cpisz@austin.rr.com>: Nov 11 02:47PM -0600 On 11/11/2016 4:58 AM, Paavo Helde wrote: > just by casting? > Cheers > Paavo I don't. :) Some other guy was suggesting on stack overflow, that is the intended use of this boost function. I just did not know how to explain to him that it surely wasn't, aside from "bad". Now I do! Now I am convinced. I guess there is no way for me to really validate a path aside from using it. Thanks for clearing it up. |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 12 01:28AM +0200 On 11.11.2016 22:47, Christopher J. Pisz wrote: > that it surely wasn't, aside from "bad". Now I do! > Now I am convinced. I guess there is no way for me to really validate a > path aside from using it. That's a good idea. You cannot validate fully anyway because the file may reside in any kind of network-mapped directory of a foreign filesystem with its own rules. The filenames are also often abused to pass through some extended functionality, so if your validator is over-eager it might forbid some potentially useful names like \\?\UNC\foo\bar or file://C|/foo/bar. BTW, the declaration of boost::filesystem::native() in Boost headers is commented as: // name_checks // These functions are holdovers from version 1. It isn't clear they have much // usefulness, or how to generalize them for later versions. So it seems this is just random crap left over from older times. Indeed, as mentioned in SO comments, it even accepts * as a valid filename character! Anyway, the native Windows SDK interface works with strings in UTF-16 encoding, so any function defined in terms of std::string and claiming to work with Windows filenames is pretty suspicious (unless it is clearly stated that they use UTF-8 encoding, which is indeed capable of properly representing UTF-16). I see that boost::filesystem::path uses 16-bit wchar_t on Windows, which makes a lot more sense. Cheers Paavo |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 11 04:14PM > users so didn't feel like I needed it. On the other hand, > I hope to have a lot of users so maybe it would be a good > idea. What do you think? Thanks in advance. It's a good idea. Even if you just do the bare minimum: set up a copy of your repository there and do 'git push github' once in a while. You don't have to focus your work around it if you don't want to. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| woodbrian77@gmail.com: Nov 11 11:44AM -0800 On Friday, November 11, 2016 at 10:14:31 AM UTC-6, Jorgen Grahn wrote: > It's a good idea. Even if you just do the bare minimum: set > up a copy of your repository there and do 'git push github' > once in a while. I'm going to try Atlassian as Rick suggested. I'll probably try their command line option before their GUI as you hint at here. > You don't have to focus your work around it if you don't want to. Good point. Brian Ebenezer Enterprises - "I want you to know how hard I am working for you and for those at Laodicea, and for all who have not met me personally." Colossians 2:1 http://webEbenezer.net |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment