Re: [PATCH] Fix type errors in win32.

[Eli Zaretskii]

> From: U2FsdGVkX1 <u2fsdgvkx1@gmail.com>
> Date: Mon, 25 Oct 2021 10:55:03 +0800
> Cc: U2FsdGVkX1 <U2FsdGVkX1@gmail.com>
> 
> * src/commands.c (fatal_error_signal): DWORD type should be unsigned
> * src/dir.c (print_dir_data_base): Fix format type mismatch
> * src/function.c (windows32_openpipe): Use the WINAPI GetStdHandle function 
> instead
> * src/getopt.c (_getopt_internal): Improve code readability

Thanks.  A couple of comments to some of the hunks you propose:

> --- a/src/dir.c
> +++ b/src/dir.c
> @@ -1119,7 +1119,7 @@ print_dir_data_base (void)
>            else if (dir->contents->dirfiles.ht_vec == 0)
>              {
>  #ifdef WINDOWS32
> -              printf (_("# %s (key %s, mtime %I64u): could not be 
> opened.\n"),
> +              printf (_("# %s (key %s, mtime %llu): could not be opened.\n"),

This change is problematic, because the default C runtime used by Make
doesn't support %llu, at least not on Windows versions older than
Windows 10.  MinGW64 links programs by default with an extension
library of its own, which provides ANSI-compatible replacements for
printf and stuff, and those do support %llu, but we don't want to make
the sources compile only with those tools.

Are there any problems with using %I64u there? if so, what problems
did you see?

> -  tmpErr = (HANDLE)_get_osfhandle (errfd);
> +  tmpErr = GetStdHandle (errfd);

This one I don't understand.  _get_osfhandle is the documented way of
obtaining the OS handle for any CRT file descriptor, so what's wrong
with using it here?  By contrast, GetStdHandle isn't even explicitly
documented to serve this purpose, i.e. to obtain a handle from a CRT
file descriptor (since errfd comes from 'fileno').  maybe it can do
that, but why use undocumented functionality when a documented one is
available?