Re: [bug-gnulib] wait-process module

[Bruno Haible]

Derek,

> I apologize for the misunderstanding.  You hadn't replied to new points
> raised by three different people

Noone raised an important change request regarding the wait-process module in
a year.

> and in general the process on GNULIB
> has seemed to me to be that no response meant approval on this list,
> generally after about a week.

This is true regarding modules that you propose on your own, or for likely
uncontroversial changes. Not for changes for which there is doubt or even
a known objection.

But I accept your apologies. Let's talk about the patch.

It adds a new parameter, so that wait_process can inform the caller about
the way the subprocess terminated.

> Anyhow, I understood that your main objection to this patch is that this
> is not portable to Windows, and it _is_ portable to Windows.

When I say that it is _not_ portable to Windows, I mean the following:
If someone writes a program that uses the feature, the feature will not work on
Windows. The 'exitsignal' will always be 0 on Windows, even if the subprocess
died from an illegal instruction or GFP or Ctrl-Break.

The patch compiles on Windows, but that's not the point.

When a gnulib user uses a documented behaviour of a gnulib function and it works
on Linux or Solaris, it should have a reasonable probability of working on
Windows as well. That's the whole point of a "portability library".

> The new code only allows the caller to know that a signal caused the
> child to exit, *when a signal is present*.  I really don't understand
> why you think the new code should do something when a signal is not
> present.

Which exitsignal does your patch return when the subprocess on Windows
died from illegal instruction, GFP or Ctrl-Break?

> Would the addition of documentation that mentioned that signals are not
> detected (and therefore never returned) under Windows and why make the
> patch more palatable for you?

If there was no other solution to the problem, yes. But there are more portable
solutions. How about this one:
  - The subprocess, as last thing it does in main() before exit(0), sends
    to the parent process a bit of information indicating that it succeeded.
    This information can take the form of a file that is created or deleted
    on the filesystem, or of a particular byte value sent through a file
    descriptor to the parent (very easy to do if the subprocess was created
    through the pipe() function or equivalent), or similar.

This should be a solution that works portably, no?

Bruno