On Tue, Mar 04, 2014 at 06:28:17AM -0700, Eric Blake wrote: > POSIX requires that <stdlib.h> expose WIFEXITED and friends, > but FreeBSD and others fail to comply. We can work around it > manually by including <sys/wait.h>, or we can work around it > automatically by using gnulib's system-posix module. > > * bootstrap.conf (gnulib_modules): Add system-posix. > > Signed-off-by: Eric Blake <eblake(a)redhat.com&gt; > --- > > I'll wait for a review on this one - we don't use system(), > and it feels a little bit odd to list the system() module > merely for its side effect of a fixed <stdlib.h>. The alternative > is to continue using <sys/wait.h> everywhere that we use > WIFEXITED and friends. Perhaps we should have a helper in util/virprocess.{c,h} for this, so no code outside that file ever need use WIFEXITED ?

On 03/04/2014 06:59 AM, Eric Blake wrote: > On 03/04/2014 06:47 AM, Daniel P. Berrange wrote: >> On Tue, Mar 04, 2014 at 06:28:17AM -0700, Eric Blake wrote: >>> POSIX requires that <stdlib.h> expose WIFEXITED and friends, >>> but FreeBSD and others fail to comply. We can work around it >>> manually by including <sys/wait.h>, or we can work around it >>> automatically by using gnulib's system-posix module. >>> >>> * bootstrap.conf (gnulib_modules): Add system-posix. >>> >>> Signed-off-by: Eric Blake <eblake(a)redhat.com&gt; >>> --- >>> >>> I'll wait for a review on this one - we don't use system(), >>> and it feels a little bit odd to list the system() module >>> merely for its side effect of a fixed <stdlib.h>. The alternative >>> is to continue using <sys/wait.h> everywhere that we use >>> WIFEXITED and friends. >> >> Perhaps we should have a helper in util/virprocess.{c,h} for >> this, so no code outside that file ever need use WIFEXITED ? > > We already have a couple of helper functions, and my recent virFork > cleanups got rid of even more clients of WIFEXITED (that is, > virCommandRun now defaults to returning sanitized rather than raw exit > values). At this point, there are very few reasons for any new code to > need to use WIFEXITED; it's mostly limited to existing code (but where > my virFork cleanups tripped up on the FreeBSD header bug due to > refactoring). > So, should I just ditch this patch?

On 03/07/2014 10:09 AM, Daniel P. Berrange wrote: > On Fri, Mar 07, 2014 at 09:56:10AM -0700, Eric Blake wrote: >> On 03/04/2014 06:59 AM, Eric Blake wrote: >>> On 03/04/2014 06:47 AM, Daniel P. Berrange wrote: >>>> On Tue, Mar 04, 2014 at 06:28:17AM -0700, Eric Blake wrote: >>>>> POSIX requires that <stdlib.h> expose WIFEXITED and friends, >>>>> but FreeBSD and others fail to comply. We can work around it >>>>> manually by including <sys/wait.h>, or we can work around it >>>>> automatically by using gnulib's system-posix module. >>>>> >>> We already have a couple of helper functions, and my recent virFork >>> cleanups got rid of even more clients of WIFEXITED (that is, >>> virCommandRun now defaults to returning sanitized rather than raw exit >>> values). At this point, there are very few reasons for any new code to >>> need to use WIFEXITED; it's mostly limited to existing code (but where >>> my virFork cleanups tripped up on the FreeBSD header bug due to >>> refactoring). >>> >> >> So, should I just ditch this patch? > > I don't feel strongly either way. ACK if you thing it is worth doing > anyway. Roman, any thoughts, since you are the person most likely impacted by this? If we do the gnulib change, then future patches that assume POSIX semantics, and pass testing when written by developers against glibc, won't break the build on BSD; on the other hand, we've made virprocess.h useful enough that most future patches shouldn't be using WIFEXITED directly and therefore shouldn't trip up BSD compilation in the first place. Meanwhile, do you want to file a bug report to the BSD folks to fix their <stdio.h>?