https://sourceware.org/bugzilla/show_bug.cgi?id=25713
--- Comment #51 from Torbjörn SVENSSON ---
There is one more thing that I just started to think about.
The "ccs=UNICODE" part, when is that needed?
Is it a risk to have it compared to not have it?
According to MSDN[1], the ccs=UNICODE will do
https://sourceware.org/bugzilla/show_bug.cgi?id=25713
--- Comment #50 from Torbjörn SVENSSON ---
(In reply to cvs-com...@gcc.gnu.org from comment #40)
> The master branch has been updated by Nick Clifton :
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> h=cb7da2a640c405e0658c135b
https://sourceware.org/bugzilla/show_bug.cgi?id=25713
--- Comment #37 from Torbjörn SVENSSON ---
(In reply to Fred Eisele from comment #35)
> Created attachment 13990 [details]
> This patch handles long paths, relative paths, and paths containing '.' and
> '..' on WIN32
I think the conversion fr
https://sourceware.org/bugzilla/show_bug.cgi?id=25713
--- Comment #31 from Torbjörn SVENSSON ---
I agree.
Maybe it would be sufficient to check that all bytes in the provided char* is
in the ASCII range. If a the check fails, put a clear error message to the user
that the filename is not support
https://sourceware.org/bugzilla/show_bug.cgi?id=25713
--- Comment #29 from Torbjörn SVENSSON ---
(In reply to Fred Eisele from comment #28)
> However, I do not think PR 25713 is going to tackle that larger issue.
> I think it should be restricted to dealing with the filename as provided by
> the
https://sourceware.org/bugzilla/show_bug.cgi?id=25713
--- Comment #27 from Torbjörn SVENSSON ---
While the overall way to do it is covered in comment 26, there are some
problems running MultiByteToWideChar.
In the example in comment 26, it's assumed that the file path is encoded in
UTF-8, or ASCI
https://sourceware.org/bugzilla/show_bug.cgi?id=25713
Torbjörn SVENSSON changed:
What|Removed |Added
CC||torbjorn.svensson at st dot com
