Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > much happier if we set errno on SIGCHLD in patch 1 - the argument in > [1] that a non-zero errno might break something because signal() did > not set it does not make much sense to me. Not to me either. > At the moment it does not > matter because there are no callers that check the return value let > alone errno but if a future caller does start checking for errors > there going to be surprised by errno not getting set. True, again. Let's queue this round and then patch the errno issue up on top after the dust settles. "might break something" may then happen, at which time it is easier to see where that breakage came from, and we can go from there. Thanks, all.