Date: Thu, 6 Nov 1997 18:10:03 -0800 (PST) From: Torbjorn Granlund <tege@nada.kth.se> To: freebsd-bugs Subject: Re: bin/4961: Problems with fseek and fprints Message-ID: <199711070210.SAA00573@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/4961; it has been noted by GNATS. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711070210.SAA00573>