Re: [boost] [review] Review of Nowide (Unicode) starts today

Artyom Beilis wrote:

On Tue, Jun 13, 2017 at 6:08 PM, Peter Dimov via Boost wrote:

...

Artyom Beilis wrote:

...

Note, under POSIX user takes strings as is and can't trust the source. Under Windows it need to convert them using nowide which can give him false assumption that it receives valid UTF-8.

What use case are we discussing here?

Is it the one where the user gets a path from an external source and passes it to Nowide? In which case Nowide does no validation on POSIX and strict UTF-8 validation on Windows? Giving the Windows user the false assumption that Nowide validates, which turns out to not happen in a later POSIX port.

Or is it the one where the user receives a path from Nowide? Which currently doesn't occur anywhere, because the library does not return paths, it only takes them as arguments. (It would occur if you add `readdir`.)

For that purpose you have Boost.Filesystem that internally keeps wide strings on Windows and narrow on POSIX platforms.

Nowide does not try to replace Boost.Filestem. However once you try to get an std::string from Boost.Filesystem (using nowide integration) you will get either error or valid UTF-8 string.

This doesn't answer my question. Let me rephrase. The user gets a path from an external source and passes it to Nowide, for example, to nowide::fopen. Nowide does no validation on POSIX and strict UTF-8 validation on Windows. Why is the Windows-only strict validation a good thing? What attacks are prevented by not accepting WTF-8 in nowide::fopen ONLY under Windows, and passing everything through unvalidated on POSIX? If the program originates on Windows and as a result comes to rely on Nowide's strict validation, and is later ported to POSIX, are not the users left with a false sense of security?