Suggestion on portable Unicode support with libWinTF8

[m13253]

@biergaizi and I have just read init.c@7a4639a and we have found:

• operations on filenames without proper international mechanisms
• constructing command line arguments in an unsafe way
• calling system to spawn child processes

I suggest you use libWinTF8, which is written and fine-tuned by me, to satisfy the portability among Windows, OS X and Linux with Unicode support.

Consider these line in init.c:

snprintf ( tmp, CMD_BUF, "%s %s %s%s %s%c", "res\\7z.exe x", osimage, "-o", "%temp%\\", "md5sum -y > nul", '\0' ); /* NOTICE: ">nul" is not portable */
system ( tmp ); /* WTF after 7-Zip failed it still returns 0! */

Constructing command line arguments without escaping is dangerous. And system may fail if the installation path is unable to be represented in local charset. Let's look at the comment /* WTF after 7-Zip failed it still returns 0! */. That's true. According to MSDN, system does not track the return value of child process unlike in POSIX systems. Further, the buffer tmp may not be large enough. Buffer overflow is dangerous.

Luckily, libWinTF8 solves the above problems in these ways:

• providing a complete set of fopen, remove, getenv supporting UTF-8 strings as filenames
• providing the function spawnvp, which constructs the command line for you from an array (using an internal portable vasprintf implementation), according to the specification by Microsoft on escaping safely
• providing the function waitpid, which tracks child process and its return value

Although libWinTF8 is written in C++, it provides an identical C interface. libWinTF8 builds on GCC, Clang as well as MSVC 12 and by default generates a static library (.a).

Take my suggestions into consideration and thank you.

[liushuyu]

Yes, I think it is necessary to take your suggestion.

[jyhi]

Well, this is a problem which really needed to be solved. I didn't think a lot when I wrote it. This is my fault. BTW, I think it needs a great amount of work if we fix the problem. This is my fault, and I don't know whether it will cause the whole program a great reconstruct.

Anyway, thanks @m13253 @biergaizi a lot. We will try our best to fix it.

[m13253]

@lmy441900

Since our code aims to run on both Linux and Windows, I suggest you take a look at libWinTF8. I have just updated libWinTF8 today to suite your needs (including access function and 8.3 short filename generation).

I would like to cooperate with you to make the program more portable and safe.

Could you tell me from which the refactor should start first? I want to work with you.

[jyhi]

@m13253 I have had a look at libWinTF8, and it is pretty good. As for the refactor, I have no idea about it. You can modify the code as you please.

Anyway, a great thanks to your participation.