Re: [PATCH] windows-nat: Decode system error numbers

[Joel Brobecker <brobecker@adacore.com>]

> and as it stands this is printed by the debuggee GDB:
> 
> error return .../gdb/windows-nat.c:2312 was 6
> 
> but with the patch applied a proper error message is produced instead:
> 
> error return .../gdb/windows-nat.c:2332 was: The handle is invalid. (6)

This is nice, I like it.

>  This code builds and works as manually verified above; these errors
>  never trigger in the test suite so that doesn't really cover it -- my
>  understanding is they are not meant to trigger unless GDB or the
>  system is malfunctioning for some reason.

I don't know of any way to force the triggering of these errors under
"normal" circumstances either.  But I did notice that we get them
occasionally during our testsuite nightly run, with an error number
5 (permissing denied kind of thing?).

This happened when trying to kill the inferior, for instance. It's very
hard to reproduce, very rare and random, so I've never been able to get
to the bottom of it. And the only hints I got on the web was that
Borland had the same problem, and that they "fixed" it. Since I could
not observe any anomaly besides the error message (inferior was killed
as expected, for instance), I was left wondering whether Borland just
disabled the error message...

> 2011-11-09  Maciej W. Rozycki  <macro@codesourcery.com>
> 
> 	gdb/
> 	* windows-nat.c (check): Decode the error number retrieved with 
> 	GetLastError.

A Windows maintainer can approve your code.  I looked at the code, and
nothing really jumped at me, except maybe the fact that you decrement
size and use it change one element in buf at the same time. Personally,
I'm not fond of these practices in general, but I can live with that in
this case.

-- 
Joel