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