Re: [HACKERS] Win32 WEXITSTATUS too - Mailing list pgsql-patches
From | Bruce Momjian |
---|---|
Subject | Re: [HACKERS] Win32 WEXITSTATUS too |
Date | |
Msg-id | 200701231540.l0NFee508211@momjian.us Whole thread Raw |
In response to | Re: [HACKERS] Win32 WEXITSTATUS too (Magnus Hagander <magnus@hagander.net>) |
Responses |
Re: [HACKERS] Win32 WEXITSTATUS too
|
List | pgsql-patches |
Magnus Hagander wrote: > 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). Is there a portable way to get the _exception_ value from system(), rather than the error code? We could go with just > 0xC0000000 values as exceptions. (This is clearly showing the mess that is the WIN32 API.) > > > 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. The major place we use it is for backend termination checking, and we know the return values there. The other place is for the return value of pipe(). -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
pgsql-patches by date: