Kostiantyn Kostiuk <kkost...@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 <arm...@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-
