From tege@pro.tmg.se  Thu Nov  6 16:31:29 1997
Received: from pro.tmg.se (quiet.matematik.su.se [130.237.198.146])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA24876
          for <FreeBSD-gnats-submit@freebsd.org>; Thu, 6 Nov 1997 16:31:23 -0800 (PST)
          (envelope-from tege@pro.tmg.se)
Received: (from tege@localhost)
	by pro.tmg.se (8.8.5/8.8.5) id BAA12795;
	Fri, 7 Nov 1997 01:31:26 +0100 (CET)
Message-Id: <199711070031.BAA12795@pro.tmg.se>
Date: Fri, 7 Nov 1997 01:31:26 +0100 (CET)
From: tege@pdc.kth.se
Reply-To: tege@pdc.kth.se
To: FreeBSD-gnats-submit@freebsd.org
Subject: Problems with fseek and fprints
X-Send-Pr-Version: 3.2

>Number:         4961
>Category:       bin
>Synopsis:       Problems with fseek and fprints
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov  6 16:40:01 PST 1997
>Closed-Date:    Fri Nov 7 10:33:50 PST 1997
>Last-Modified:  Fri Nov  7 10:40:01 PST 1997
>Originator:     Torbjorn Granlund
>Release:        FreeBSD 2.2.2-RELEASE i386
>Organization:
TMG Datakonsult
>Environment:

Quite likely irrelevant.  (Reproducible on radically different
configurations.)

>Description:

1) fseek is ignored on files that were fdopen'ed in append mode.
2) The second fprintf below sets errno even while no error really
   happens.  Note that this incorrect behaviour happens even if
   the fseek belowcall of the test case is removed.

>How-To-Repeat:

Compile the test case below.
Then run it and redirect its output to a file.
I think it should print "errno should be zero here: 0".
But it prints "This should be overwritten;errno should be zero here: 2".

#include <unistd.h>
#include <stdio.h>
extern int errno;
main ()
{ FILE *fs;
  fs = fdopen (dup (fileno (stdout)), "a");
  fprintf (fs, "This should be overwritten;");
  fseek (fs, 0L, SEEK_SET);
  fprintf (fs, "errno should be zero here: %d\n", errno);
  exit (0); }


>Fix:

>Release-Note:
>Audit-Trail:

From: Bill Fenner <fenner@parc.xerox.com>
To: tege@pdc.kth.se
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/4961: Problems with fseek and fprints 
Date: Thu, 6 Nov 1997 17:55:52 PST

 tege@pdc.kth.se wrote:
 >1) fseek is ignored on files that were fdopen'ed in append mode.
 
 This is not a bug.  ANSI C says that writes are only allowed at the end
 of file when opening in append mode (e.g. any write has an implicit
 seek to end preceding it).  Open with "r+" if you want to write
 somewhere other than the end of file.
 
 >2) The second fprintf below sets errno even while no error really
 >   happens.
 
 errno is not set on a 2.2.2-RELEASE system; on a 3.0-CURRENT system,
 errno is indeed set to ENOENT.  Interestingly enough, it's the first
 fprintf that's setting errno.  This is definitely worth looking into;
 I have no clue what fprintf might be doing that would cause a ENOENT.
 
   Bill

From: Torbjorn Granlund <tege@nada.kth.se>
To: Bill Fenner <fenner@parc.xerox.com>
Cc: tege@pdc.kth.se, FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/4961: Problems with fseek and fprints 
Date: Fri, 07 Nov 1997 03:06:08 +0100

   >1) fseek is ignored on files that were fdopen'ed in append mode.
 
   This is not a bug.  ANSI C says that writes are only allowed at the end
   of file when opening in append mode (e.g. any write has an implicit
   seek to end preceding it).  Open with "r+" if you want to write
   somewhere other than the end of file.
 
 (Does ANSI say anything about this?  I thought POSIX was what spec'd these
 functions?)
 
 I checked several other Unices and, and they behaved as I want.  If
 FreeBSD's behaviour is right, there is no obvious way of closing say stdout
 and reopen what was associated to it and then keep writing to a specified
 position.  "w" truncates the file and "r+" cannot be done on stdout since
 the underlying file descriptor disallows reads.
 
   >2) The second fprintf below sets errno even while no error really
   >   happens.
 
   errno is not set on a 2.2.2-RELEASE system; on a 3.0-CURRENT system,
   errno is indeed set to ENOENT.  Interestingly enough, it's the first
   fprintf that's setting errno.  This is definitely worth looking into;
   I have no clue what fprintf might be doing that would cause a ENOENT.
 
 Well, I discovered the behaviour on a 2.2.1/2.2.2 bastard system,
 so I think the bug happens there!
 
 Torbjorn

From: Bill Fenner <fenner@parc.xerox.com>
To: fenner@parc.xerox.com, tege@nada.kth.se
Cc: FreeBSD-gnats-submit@freebsd.org, tege@pdc.kth.se
Subject: Re: bin/4961: Problems with fseek and fprints
Date: Thu, 6 Nov 1997 18:15:37 PST

 The ANSI C Standard, section 7.9.5.3, says:
 
 
 Opening a file with append mode ('a' as the first character in the mode
 argument) causes all subsequent writes to the file to be forced to the then
 current end-of-file, regardless of intervening calls to the fseek function.
 
 
 I don't know how to do what you want to do with ANSI C.
 
   Bill

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: Bill Fenner <fenner@parc.xerox.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/4961: Problems with fseek and fprints 
Date: Thu, 6 Nov 1997 22:31:51 -0500 (EST)

 <<On Thu, 6 Nov 1997 18:00:02 -0800 (PST), Bill Fenner <fenner@parc.xerox.com> said:
 
 >  errno is indeed set to ENOENT.  Interestingly enough, it's the first
 >  fprintf that's setting errno.  This is definitely worth looking into;
 >  I have no clue what fprintf might be doing that would cause a ENOENT.
  
 fprintf()
 	stdio internals
 		malloc()
 			malloc internals
 				readlink("/etc/malloc.conf", ...)
 
 -GAWollman
 
 --
 Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
 wollman@lcs.mit.edu  | O Siem / The fires of freedom 
 Opinions not those of| Dance in the burning flame
 MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick

From: Bill Fenner <fenner@parc.xerox.com>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/4961: Problems with fseek and fprints 
Date: Thu, 6 Nov 1997 21:05:50 PST

 Garrett Wollman <wollman@khavrinen.lcs.mit.edu> wrote:
 >				readlink("/etc/malloc.conf", ...)
 
 Aha.  Plaugher's "Standard C Library" says that the "right" way
 to use errno is:
 
 	errno = 0;
 	foo();
 	if (errno) ...
 
 so library functions shouldn't set errno if an error did not occur.
 Does that mean that malloc should save errno around the readlink()?
 
   Bill

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: Bill Fenner <fenner@parc.xerox.com>
Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>,
        freebsd-gnats-submit@freebsd.org
Subject: Re: bin/4961: Problems with fseek and fprints 
Date: Fri, 7 Nov 1997 09:33:55 -0500 (EST)

 <<On Thu, 6 Nov 1997 21:05:50 PST, Bill Fenner <fenner@parc.xerox.com> said:
 
 > Aha.  Plaugher's "Standard C Library" says that the "right" way
 > to use errno is:
 
 > 	errno = 0;
 > 	foo();
 > 	if (errno) ...
 
 > so library functions shouldn't set errno if an error did not occur.
 > Does that mean that malloc should save errno around the readlink()?
 
 Applications should not inspect errno unless a library call which is
 documented as setting it returned an error indication.  If there is no
 error indicated, there is still no guarantee that errno will keep its
 value.  It was done this way specifically to permit the traditional
 implementation of stdio, which calls isatty() to determine whether to
 buffer output or not (and in the latter case, isatty() has the side
 effect of setting errno to ENOTTY).
 
 Unless an error is indicated, the value of errno is indeterminate.
 
 -GAWollman
 
 --
 Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
 wollman@lcs.mit.edu  | O Siem / The fires of freedom 
 Opinions not those of| Dance in the burning flame
 MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick
State-Changed-From-To: open->closed 
State-Changed-By: fenner 
State-Changed-When: Fri Nov 7 10:33:50 PST 1997 
State-Changed-Why:  
As stated in the audit-trail, ANSI C mandates the "a" behavior 
(section 7.9.5.3) and allows the errno behavior (section 7.1.4). 

From: Bill Fenner <fenner@parc.xerox.com>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/4961: Problems with fseek and fprints 
Date: Fri, 7 Nov 1997 10:33:24 PST

 Garrett Wollman <wollman@khavrinen.lcs.mit.edu> wrote:
 >Unless an error is indicated, the value of errno is indeterminate.
 
 That's what I always thought, too.  Footnote #93 of the ANSI C standard says:
 
 ... a program that uses errno for error checking should set it to
 zero before a library function call, then inspect it before a subsequent
 library function call.
 
 However, the ANSI C standard also says
 
 The value of errno may be set to nonzero by a library function call
 whether or not there is an error...
 
 so it seems to be inconsistent with itself.  Oh well.
 
   Bill
>Unformatted:
