Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!steinmetz!uunet!mcvax!ruuinf!piet
From: piet@ruuinf.UUCP (Piet van Oostrum)
Newsgroups: comp.sys.atari.st
Subject: Re: File handle info
Message-ID: <479@ruuinf.UUCP>
Date: 2 Jun 88 08:55:15 GMT
References: <465@ruuinf.UUCP> <1066@atari.UUCP>
Organization: Univ of Utrecht, Dept of CS
Lines: 23
In-reply-to: kbad@atari.UUCP's message of 31 May 88 22:59:37 GMT

In article <1066@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:

   in article <465@ruuinf.UUCP>, piet@ruuinf.UUCP (Piet van Oostrum) says:
   > what I think is the easiest way to do it: if you seek to an illegal
   > position (like -1), you get an error (-64) if the file is on disk,
   > otherwise you get 0. If the file is on disk, its position is not changed,
   > so the operation is effectively always a no-op.

     That may be an easy way to do it, but I wouldn't recommend relying on
   an undocumented feature of what Fseek returns.  Hardly safe.

I agree. So, *WHAT* is the documented return value from Fseek, especially
in the case I use. I never saw any description of Fseek telling what the
return code (except in case of an error) is. Is the return code you use
(the actual position in the file, 0 for a non-file) documented?

In fact if it is documented to ALWAYS return 0 on a terminal, then my code
is reliable.

-- 
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands
Telephone: +31-30-531806              UUCP: ...!mcvax!ruuinf!piet