Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.lang.c
Subject: Re: ANSI draft - seeking to eof
Message-ID: <189@brl-tgr.ARPA>
Date: Fri, 29-Nov-85 23:29:00 EST
Article-I.D.: brl-tgr.189
Posted: Fri Nov 29 23:29:00 1985
Date-Received: Sun, 1-Dec-85 03:14:42 EST
References: <5400018@prism.UUCP>
Organization: Ballistic Research Lab
Lines: 24

> The latest (November 11) draft from X3J11 says this about fseek():
> 
> 	int fseek (FILE *stream, long offset, int ptrname)
> 	
> 	A binary stream need not meaningfully support fseek
> 	calls with a ptrname value of SEEK_END.
> 
> 	For a text stream, either offset must be zero, or
> 	offset must be a value returned by an earlier call
> 	to ftell on the same stream and ptrname must be 
> 	SEEK_SET.			
> 				[X3J11/85-138, page 109]
> 
> Does this really mean that there's no guaranteed way to seek to the end of
> either a text or a binary stream in ANSI C (when such a beast exists)?

It says you can seek to the end of a text stream but not a binary
stream.  This is interesting; one wonders what systems they had
in mind that can do the one but not the other.

By the way, UNIX I/O is meant to qualify as "text stream".  There
was a problem in the wording that we turned up in P1003 (apparently
would require all UNIX files to end with a newline byte); I don't
know whether X3J11 has fixed this by now, but I sure hope so.