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.
> 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.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +