linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
	chet.ramey@case.edu, linux-fsdevel@vger.kernel.org,
	bug-bash@gnu.org, chet@po.cwru.edu
Subject: Re: bash: Correct usage of F_SETFD
Date: Tue, 23 Nov 2010 07:51:58 -0700	[thread overview]
Message-ID: <4CEBD50E.7050405@redhat.com> (raw)
In-Reply-To: <20101123144239.GL6178@parisc-linux.org>

[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]

On 11/23/2010 07:42 AM, Matthew Wilcox wrote:
> The POSIX definition can be found here:
> http://www.opengroup.org/onlinepubs/009695399/functions/fcntl.html
> 
>> | In practice, there aren't any such systems; but POSIX warns that current
>> | practice is no indicator of future systems, and that read-modify-write
>> | is the only way to use F_SETFD.
>>
>> Yes, that seems to make more sense.
> 
> I think future flags will be created such that they default to off,
> and bash would have to affirmitively set them in order to use them.

Not true.  An implementation can reasonably define a new flag to off for
backwards-compatible behavior, and on for POSIX-compatible behavior, if
there is a case where traditional and POSIX behavior differ.  POSIX
permits additional bits to be on, and in fact requires that applications
leave those additional bits unchanged, in the very case where those
additional bits are essential for maintaining a POSIX-compatible
environment.

> 
> So if bash is the one creating its file descriptors, there's no need to
> use R/M/W since it knows what the state of them are.

No, bash cannot reasonably know what the implementation's default bit
state is, and blindly setting all other bits to zero is very possibly a
bug, and easy enough to avoid by using the full R/M/W.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

  reply	other threads:[~2010-11-23 14:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22 20:16 bash: Correct usage of F_SETFD Sukadev Bhattiprolu
2010-11-22 22:16 ` Chet Ramey
2010-11-22 22:27   ` Eric Blake
2010-11-23  0:04     ` Sukadev Bhattiprolu
2010-11-23 14:42       ` Matthew Wilcox
2010-11-23 14:51         ` Eric Blake [this message]
2010-11-23 17:51           ` Sukadev Bhattiprolu
2010-11-24  1:17     ` Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CEBD50E.7050405@redhat.com \
    --to=eblake@redhat.com \
    --cc=bug-bash@gnu.org \
    --cc=chet.ramey@case.edu \
    --cc=chet@po.cwru.edu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=sukadev@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).