[re-adding the list] On 03/29/2010 04:39 PM, Christian Weisgerber wrote: >> I'm still trying to get access to a FreeBSD 7 box to test this out >> myself (my current FreeBSD access is running 8.0, but that does not >> have the bug). > > Well, you can temporarily remove the prototype for fdopendir() from > <dirent.h>. > > Your changes look correct to me, and I've wedged them into GNU tar > 1.23 on my FreeBSD 7.3/amd64 box and they work.
Thanks for the feedback. Yeah, I suppose I could temporarily corrupt a
non-FreeBSD system for an equally effective test.
>
> Minor remarks:
>
>> --- a/m4/fdopendir.m4
>> +++ b/m4/fdopendir.m4
>> @@ -35,4 +35,9 @@ AC_DEFUN([gl_FUNC_FDOPENDIR],
>> AC_LIBOBJ([fdopendir])
>> fi
>> fi
>> + dnl FreeBSD 7.3 has the function, but failed to declare it.
>> + AC_CHECK_DECLS([fdopendir], [], [HAVE_DECL_FDOPENDIR=0], [[
>> +#include <dirent.h>
>> +#include <fcntl.h>
>> + ]])
>> ])
>
> The <fcntl.h> is useless; the preceding test only uses it to pull
> in O_RDONLY. *BSD documents that <sys/types> should be included
> before <dirent.h>, but in practice that isn't necessary.
Thanks for the pointers. We haven't yet encountered a system where
<dirent.h> in isolation fails to compile, but I will fix the <fcntl.h>
inclusion.
>
> If you are really paranoid, you need to provide a prototype here...
>
> [int fd = open ("conftest.c", O_RDONLY);
> if (fd < 0) return 2;
> return !!fdopendir (fd);])],
>
> ... because fdopendir() could return a valid pointer whose lower
> 32 bits just happen to be 0, as unlikely as that is in practice.
> But then only some versions of FreeBSD lack the prototype, and
> FreeBSD's fdopendir() does not accept a file handle from a non-directory
> file.
Worth incorporating into my patch, then. I'll post my respin, once I've
tested locally.
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
