On Friday, October 03, 2014 02:06:34 PM Daniel Stenberg wrote:
> On Mon, 29 Sep 2014, clinton_at_elemtech.com wrote:
> >> "This problem" is at least two separate ones: 1 - what the URL should
> >> look
> >> like to allow a unicode file name to get opened and 2 - have the actual
> >> file: code understand and work with a file name provide according to
> >> (1).>
> > Thanks for the discussion. It seems like you only have concerns about the
> > second patch. If percent encoded UTF-8 is used, then only the first patch
> > is needed to fix the problem.
> >
> > Are you OK with that solution?
>
> I think so, assuming it doesn't break old existing functionality and ways of
> working. Do those function calls you use work in all Windows versions?

It could break those which don't follow RFC 3986 for handling non-ascii
characters. On the other hand, it currently doesn't work for those with non-
ascii filenames which do follow RFC 3986.

The introduced _wopen works on Win NT 4.0, Win 2000, WinXP, and newer.
The introduced MultiByteToWideChar/WideCharToMultiByte support Windows 98,
Windows 2000 and newer. If using Windows 2000 SP4 and newer, then a flag can
be added to check for invalid characters. Doing so would allow this kind of
error to be returned:
"curl: (3) URL using bad/illegal format or missing URL"

When you say *all* Windows versions... are you including Windows 3.1, Windows
95, etc... ??
Where is the cut-off?

>
> Then, please make sure that your code checks for failures and bails out
> nicely on OOM or other errors with no memory leaks. I spotted at least two
> malloc() calls...

Yeah. I can fix that using conventions used elsewhere in libcurl.

Thanks,
Clint
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-10-04