Re: Bug: tests/fsync.c: don't check for fsync failure on invalid fd

[Eric Blake]

On 03/13/2013 07:55 AM, Phillip Susi wrote:
> Please use your mail agent's reply-to-all function on public mailing
> lists.  I did not see this until now because I am not subscribed, and
> then I had to download and import the archive to reply properly.

I did, both in my original reply, and again today.

> 
> On 2/15/2013 3:59 PM, Eric Blake wrote:
>> On 02/15/2013 12:40 PM, Phillip Susi wrote:
>>> tests/test-fsync.c asserts that fsync() fails with -EBADF when
>>> given an invalid fd.  This fails when using the libeatmydata
>>> LD_PRELOAD library to turn all fsyncs into silent noops.
> 
>> That's a bug in the libeatmydata library; I'm not sure it is worth 
>> working around in gnulib.
> 
> How is it a bug in libeatmydata?  There is no action, so there is
> nothing to fail.

There may be no syncing action, but it is still reasonable to ensure
that the fd is still valid enough to be sync'd.  It's a single fcntl()
call to prove whether an fd is valid.

>  Why does gnulib care that it fails when used
> wrongly?

Because POSIX mandates an EBADF error, and your LD_PRELOAD should not be
breaking those semantics.

>  That's a bit like dereferencing an invalid pointer and
> complaining that you didn't get a SEGV.

No, POSIX makes a difference about invalid pointers having undefined
behavior (to allow both SEGV or returning an errno of EFAULT) vs.
invalid fds (whether out of range, or in range but closed) being
mandated to fail with EBADF.

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

signature.asc
Description: OpenPGP digital signature