Re: [PATCH] util: win32: Write hex value when can't get error message

[Markus Armbruster <armbru@redhat.com>]

Kostiantyn Kostiuk <kkostiuk@redhat.com> writes:

> Issue reported to GLib https://gitlab.gnome.org/GNOME/glib/-/issues/3740
> PR with fix https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4716
>
> @Markus Armbruster <armbru@redhat.com>
> Based on the documentation from this PR, do you have any other objections
> to this patch?

I can't see that the commit invalidates my objection.

The revised contract still specifies the error code comes from
GetLastError() or WSAGetLastError().  Passing anything else still
violates it.

What can go wrong when we pass some other integer?

Say we pass EINVAL.  It's 22 on Linux.  Interpreted as Windows system
error code (the thing GetLastError() returns), that's ERROR_BAD_COMMAND,
documented as "The device does not recognize the command."[*].
g_win32_error_message() and thus error_setg_win32() will report
confusing nonsense.

Another common integer error code is -1.  This isn't a valid Windows
system error code, so we can expect to hit the "unknown Windows error"
branch.

Perhaps the code is so confused about error codes that passing them to
an appropriate function is impractical, and taking our chances with
g_win32_error_message() is the best we can do.  Wouldn't exactly inspire
confidence in the soundness of QEMU's Windows code.




[*] https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-