Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site phs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!bellcore!decvax!mcnc!duke!phs!lisa
From: lisa@phs.UUCP (Jeffrey William Gillette)
Newsgroups: net.micro.pc
Subject: Re: Lattice "C" Problem
Message-ID: <1025@phs.UUCP>
Date: Sat, 4-May-85 20:59:47 EDT
Article-I.D.: phs.1025
Posted: Sat May  4 20:59:47 1985
Date-Received: Mon, 6-May-85 01:44:39 EDT
Organization: Duke Physiology
Lines: 24

Re: Lattice \"C\" Problem
[]

> Has anyone seen a problem like this with Lattice "C", Version
> 2.14 running under MS-DOS version 2.13? A file opens o.k. with fopen,
> stuff gets stored and fclose gives a good return code, but when I examine
> the file using 'dir', it has 0K. It only happens sometimes (Of course!).

Don't know if this has any thing to do with your question, but I have
also had more than a little consternation with Lattice file i/o.  It 
seems that Lattice opens files in one of two modes ("a" for text, "b"
for binaries).  The difference is supposed to be the more sophisticated
handling of newline delimiter sequences in the "a" (text) mode.  In my
copy (version 2.10) performing a tell/seek or rewind on a file opened in the
"a" mode regularly yields incorrect results (usually off by some random
integer times the number of newline sequences encountered thus far).

I'm not sure whether Lattice has addressed this problem in recent 
revisions, but it does me no good to have a "UNIX compatible" file mode
on my C compiler if I can't use basic UNIX functions to control the
file!

Jeffrey William Gillette	...!duke!phs!lisa
Duke University