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