Re: [HACKERS] Win32 WEXITSTATUS too

On Tue, Jan 23, 2007 at 10:26:29AM -0500, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > On Tue, Jan 23, 2007 at 10:11:58AM -0500, Bruce Momjian wrote:
> > > Magnus Hagander wrote:
> > > > > > I think that's incorrect information to the user :-(
> > > > > > If the child terminates with exit(1), we will then say "child process
> > > > > > was terminated by exception 1. This seems to be a bug", which is clearly
> > > > > > not true.
> > > > > >
> > > > > > Unless you know a sure way of determining if the exitcode is a normal
> > > > > > exitcode or an exception code.
> > > > >
> > > > > Current CVS believes values >= 0x100 are non-exit() terminations.
> > > >
> > > > Why does it do that :-) That's clearly wrong. There are plenty of
> > > > exitcodes > 0x100 that aren't exceptions.
> > >
> > > Please read include/port/win32.h comment section on this and then reply.
> > > We only care about non-exit() exits.
> >
> > Right. I did. and exit() can return a lot of error codes > 0x100. For example,
> > a simple:
> > int main(int argc, char *argv) {
> > exit(12345);
> > }
>
> Yes, I know it works, but it can return 0xc0000005 too. I think we have
> to be reasonable and say >= 0x100 is probably the OS.

Depends on what you mean with OS.
There are a *lot* of tools that will return exitcodes >0x100 that are
part of the OS. As a relevant example, Windows installer will return
exitcode 3010 means "needs to reboot but didn't reboot". MSI is a part
of the OS, but it's not kernel... Same thing for things like the service
control manager (trying to operate on a service that has been removed
gives you error 1060).

> > would break that assumption. (And yes, it works)
> > exit() takes a 32-bit signed integer, and that's what comes out to the
> > calling program (verified both with console and standalone program)
> >
> > The MSDN link referes to the DDK which has to do with driver
> > development, not userspace. AFAIK, that list is not relevant here, and
> > I've seen no actual reference so far that it should be used to look up
> > exit codes.
> >
> > Now, if we're only caring about exit() from *postgresqls own processes*,
> > that might hold true. In which case I withdraw that objection as long as
> > the comment i updated to reflect this ;-) But if we're talking about
> > exit() in general of any process, then it's simply wrong.
>
> Right, that code is only used by the backend and tools.

We should be very clear about that in our comment then, and the current
comment is not. And the part referring to the DDK should just be
removed, because it's simply incorrect.

For example, don't we call cmd for PITR scripts? If we're using any of
these macros on the return value from there we are *NOT* certain of what
it will be, and then need to document that as a requirement on those
scripts.

//Magnus