archive mirror
 help / color / mirror / Atom feed
From: jw schultz <>
Subject: Re: Bug in open() function (?)
Date: Sat, 12 Jul 2003 05:04:49 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sat, Jul 12, 2003 at 11:37:08AM +0200, Andries Brouwer wrote:
> On Sat, Jul 12, 2003 at 02:14:43AM -0400, 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 .
> (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.)

I'd be inclined to at least drop the parenthetic, it only
confuses things.  The alternative would be to tie the
parenthetic to the FIFO and device files.

I'll grant that O_RDONLY would cause one to expect that the
file would not be modified in any way so truncating it on a
read-only seems wrong but that does fall under the
definition of undefined so is not contrary to the

Anyone depending on undefined behaviour is asking for
trouble.  Given that there is code floating around expecting
O_TRUNC|O_RDONLY to truncate, caution should be applied in
changing this.

I'd suggest replacing this text to match that of SUSv3 which
is much clearer.  Perhaps with the addition of a clause
stating "The use of O_TRUNC in combination with O_RDONLY to
truncate files is deprecated" or something to that effect.

|		If the file exists and is a regular file,
|		and the file is successfully opened O_RDWR
|		or O_WRONLY, its length shall be truncated
|		to 0, and the mode and owner shall be
|		unchanged. It shall have no effect on FIFO
|		special files or terminal device files. Its
|		effect on other file types is
|		implementation-defined. The result of using
|		O_TRUNC with O_RDONLY is undefined.

	J.W. Schultz            Pegasystems Technologies
	email address:

		Remember Cernan and Schmitt

  reply	other threads:[~2003-07-12 11:50 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
2003-07-12 12:04                 ` jw schultz [this message]
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:

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

  git send-email \ \ \ \

* 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).