Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucla-cs.ARPA
Path: utzoo!linus!decvax!ittatc!dcdwest!sdcsvax!sdcrdcf!ucla-cs!jimc
From: jimc@ucla-cs.UUCP
Newsgroups: net.lang.c
Subject: Re: ANSI draft - seeking to eof
Message-ID: <7931@ucla-cs.ARPA>
Date: Mon, 9-Dec-85 13:03:29 EST
Article-I.D.: ucla-cs.7931
Posted: Mon Dec  9 13:03:29 1985
Date-Received: Wed, 11-Dec-85 22:03:19 EST
References: <5400018@prism.UUCP> <189@brl-tgr.ARPA>
Reply-To: jimc@ucla-cs.UUCP (Jim Carter)
Organization: UCLA Computer Science Department
Lines: 21

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():
>> 	int fseek (FILE *stream, long offset, int ptrname)
>> 	A binary stream need not meaningfully support fseek
>> 	calls with a ptrname value of SEEK_END.
>> 				[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.
>
For one, CP/M records the ending block of a file but not the byte within
block.  If you want to know where the end is you (the library routine) have
to insert some code, like ^Z for text, and look for it on reading, or search
the last block for it on fseek(,,SEEK_END).  Obviously this doesn't work in
binary files. Often the application program has records of the form: byte
count, record type, binary data; and one of the types means EOF.

James F. Carter            (213) 206-1306
UCLA-SEASnet; 2567 Boelter Hall; 405 Hilgard Ave.; Los Angeles, CA 90024
UUCP:...!{ihnp4,ucbvax,{hao!cepu}}!ucla-cs!jimc  ARPA:jimc@locus.UCLA.EDU