> From: U2FsdGVkX1 <u2fsdgv...@gmail.com> > Date: Mon, 25 Oct 2021 10:55:03 +0800 > Cc: U2FsdGVkX1 <u2fsdgv...@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?