[libvirt] [PATCH] build: work around FreeBSD stdlib.h bug

Eric Blake eblake at redhat.com
Fri Mar 7 18:40:09 UTC 2014


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>?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140307/338dc0ac/attachment-0001.sig>


More information about the libvir-list mailing list