linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andries Brouwer <aebr@win.tue.nl>
To: Valdis.Kletnieks@vt.edu
Cc: Andrew Morton <akpm@osdl.org>,
	jcwren@jcwren.com, linux-kernel@vger.kernel.org
Subject: Re: Bug in open() function (?)
Date: Sat, 12 Jul 2003 11:37:08 +0200	[thread overview]
Message-ID: <20030712093708.GA21282@win.tue.nl> (raw)
In-Reply-To: <200307120614.h6C6EhSe019742@turing-police.cc.vt.edu>

On Sat, Jul 12, 2003 at 02:14:43AM -0400, Valdis.Kletnieks@vt.edu wrote:

> On Fri, 11 Jul 2003 22:23:00 PDT, Andrew Morton said:
> 
> > We've lived with it for this long.
> 
> Well... you have a point there..
> 
> > Given that the behaviour is undefined, the behaviour which we should
> > implement is clearly "whatever 2.4 is doing".  So let's leave it alone.
> 
> I suppose I could live with that *IF* somebody fixes 'man 2 open' to
> reflect reality.

Corrections and additions to manpages are always welcome.
Mail to aeb@cwi.nl .


(Concerning the topic under discussion, the man page says

       O_TRUNC
              If  the  file  already exists and is a regular file
              and the open mode allows writing (i.e.,  is  O_RDWR
              or  O_WRONLY) it will be truncated to length 0.  If
              the file is a FIFO or  terminal  device  file,  the
              O_TRUNC  flag  is  ignored. Otherwise the effect of
              O_TRUNC is unspecified.

which is precisely right. It continues

                                       (On many Linux versions it
              will  be  ignored; on other versions it will return
              an error.)

where someone may read this as if this is an exhaustive list of
possibilities. So adding ", or actually do the truncate" will
clarify.)


Concerning the desired behaviour: if I recall things correctly
doing the truncate was old SunOS behaviour, not doing it,
that is, honouring the O_RDONLY, is new Solaris behaviour.
Maybe someone with access to such machines can check.

Software exists that does O_RDONLY | O_TRUNC.

Andries


  reply	other threads:[~2003-07-12  9:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-12  1:17 [PATCH] [2.5] adding ppp xon/xoff support Samuel Thibault
2003-07-12  1:30 ` Paul Mackerras
2003-07-12  2:42   ` Samuel Thibault
2003-07-12  3:09     ` Bug in open() function (?) J.C. Wren
2003-07-12  3:38       ` Andrew Morton
2003-07-12  5:11         ` Valdis.Kletnieks
2003-07-12  5:23           ` Andrew Morton
2003-07-12  6:14             ` Valdis.Kletnieks
2003-07-12  9:37               ` Andries Brouwer [this message]
2003-07-12 12:04                 ` jw schultz
2003-07-12  5:39           ` J.C. Wren
2003-07-26 21:35     ` [PATCH] [2.6] adding xon/xoff support to ppp Samuel Thibault
2003-07-17  7:54 Bug in open() function (?) Michael Kerrisk
2003-07-17 10:54 ` Andries Brouwer

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=20030712093708.GA21282@win.tue.nl \
    --to=aebr@win.tue.nl \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@osdl.org \
    --cc=jcwren@jcwren.com \
    --cc=linux-kernel@vger.kernel.org \
    /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).