Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site hadron.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!lll-crg!seismo!rlgvax!hadron!jsdy
From: jsdy@hadron.UUCP (Joseph S. D. Yao)
Newsgroups: net.lang.c
Subject: Re: ANSI draft - seeking to eof
Message-ID: <107@hadron.UUCP>
Date: Sat, 30-Nov-85 09:32:29 EST
Article-I.D.: hadron.107
Posted: Sat Nov 30 09:32:29 1985
Date-Received: Mon, 2-Dec-85 03:30:25 EST
References: <5400018@prism.UUCP> <189@brl-tgr.ARPA>
Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Lines: 29
Summary: Where is seek to eof undefined?

In article <189@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes:
>> The latest (November 11) draft from X3J11 says this about fseek():
>> 	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
>> 	                            ... ptrname must be 
>> 	SEEK_SET.			
>> 				[X3J11/85-138, page 109]
>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.

OK, offset may be zero and ptrname may be SEEK_END for text files.

It seems to me that the problem with binary files on toy "operating
systems" like CP/M and MS/DOS (;-)flame repellent;-)) is not so
much that they can't seek to EOF as that EOF is indeterminate.
I.e., do you want to seek to the end of the last block, or to some
byte that might possibly mark EOF, or to the end of the data in
the file (indeterminate!!!), or what?  I've noticed this problem
when using different utilities on the same file (or the same utility
on different files) on my "toy" (;-)) machines.  By analogy, you
might think of tar files, if you've ever od'ed any, which contain
a multitude of garbage in the last part of the last block which is
only ignored due to the fact that the size is in the header -- which
is not necessarily the case in toy OS's.
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}