Re: [Bug-wget] patch: Stored file name coversion logic correction

[lifenjoiner]

Hi Tim,

First, sorry for not subscribing the mailing lists. The reply is formatted 
manually, trying to keep the style :)

>> Hi there,
>> 
>> 
>> 
>> I got this on a non-ASCII environment. The local path contains non-ASCII
>> characters with OEM ANSI encoded. So, we should convert the server responded
>> file name before it is concatenated to the local path. Not after that. Or,
>> it will cause error in the next 'iconv' function .
>
>Hi,
>
>sounds reasonable, but please provide further info to reproduce the issue.
>
>I have a non-ASCII environment as well, and moved the whole Wget project into 
>some non-ASCII subdirectory (äöü/). At least some of the *-iri-* should have 
>failed, but all succeeded.
>
Platform: Windows, console code page is 936
'wget -V':
"
GNU Wget 1.19.1 built on mingw32.
-cares +digest -gpgme +https +ipv6 -iri +large-file -metalink -nls
+ntlm +opie -psl +ssl/openssl
"
iconv: win-iconv

Attaching compiled file is not a good idea. And you are on Linux. Others can 
get a substitute from https://eternallybored.org/misc/wget/ .
And a screenshot is attached :)

>Btw, your patch introduces a memory leak (fname_len_check will be 
>overwritten). And what about the 'else' case ?
>
I think:
'convert_fname' function will free the original memory when succeed. Same as 
'fname' converted. leak?
If 'replaced_filename' is provided, get the 'else' case, it is the local 
encoding and not need conversion.

>Regards, Tim

Regards,
YX Hao

iconv-err.png
Description: PNG image