Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!rutgers!mtune!codas!usfvax2!chips
From: chips@usfvax2.UUCP (Chip Salzenberg)
Newsgroups: comp.lang.c
Subject: Re: Distorting fseek semantics
Message-ID: <832@usfvax2.UUCP>
Date: Sun, 13-Sep-87 17:54:47 EDT
Article-I.D.: usfvax2.832
Posted: Sun Sep 13 17:54:47 1987
Date-Received: Tue, 15-Sep-87 04:30:16 EDT
References: <493@its63b.ed.ac.uk> <6061@brl-smoke.ARPA> <8560@utzoo.UUCP> <8993@ut-sally.UUCP>
Organization: AT Engineering, Tampa, FL
Lines: 30
Summary: Backwards

In article <8993@ut-sally.UUCP>, nather@ut-sally.UUCP (Ed Nather) writes:
> In article <27734@sun.uucp>, guy@sun.uucp (Guy Harris) writes:
> > 
> > I have no idea how UNIX-like the "fseek" on MS-DOS C implementations really
> > is.  
> 
> It's not so bad.  If the file is opened as a text file, it works just like
> Unix, since the CR code is removed on input and restored on output.  If,
> however, the file is opened in binary, then you must use ftell() to find
> out where you are.
> -- 
> Ed Nather

Well, almost.  Nice try, Ed.  :-)  A closer model of the truth:

If you open in text mode, then CR's are stripped and the NL's remain as line
terminators.  This makes text-oriented UNIX code work, but it breaks code
that assumes that if you read 50 bytes, that your file position is advanced
by 50.  There is also the difficulty that a Control-Z is considered as an
end-of-file, but fseek(..., 2) doesn't know where the Control-Z (if any) is.

When writing a text mode file, CR's are inserted.  Similar seeking problems.

If you open in binary mode, fseek() and ftell() have the same semantics as
UNIX -- but the g(l)orious MS-DOS file format is visible to the program,
CR's, Control-Z's, and all.
-- 
Chip Salzenberg            UUCP: "uunet!ateng!chip"  or  "chips@usfvax2.UUCP"
A.T. Engineering, Tampa    Fidonet: 137/42    CIS: 73717,366
"Use the Source, Luke!"    My opinions do not necessarily agree with anything.