Lattice \"C\" Problem

[matt at prism.UUCP]

/**** prism:net.lang.c / brl-tgr!PAWKA / 10:09 pm  May 85, 19783 ****/

	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!).
Reminds me of a problem I had with a supersoft compiler until I finally
discovered you had to set a dynamic memory variable, even though you
weren't using it, before that the program gave different results at different
times. Thanks for any help anyone can give,
						Mike
					ARPA:   PAWKA at NOSC-TECR.ARPA
/* ---------- */

This may or may not have anything to do with your problem, but it is an
(almost) undocumented feature of MS-DOS that issuing the write system call
(via write(), fwrite(), etc.) with a length parameter of zero TRUNCATES the
file being written to at the current seek pointer position.  (It took me
about 3 days of all-night debugging sessions to discover this!)

If for some reason you have ever done a rewind(fp) or fseek(fp, 0L, 0) on the
file and then tried to write 0 bytes, your file will be truncated to 0 bytes
length.  Fclose will close it properly, but it will be empty.

Yes, it's a pain in the a**, and Lattice and/or Microsoft really should have
documented it in the Lattice and/or MS-DOS documentation, but it DOES make
writing the 4.2-style truncate() and ftruncate() calls easy :-) 

-----------------------------------------------------------------------------
 Matt Landau            {cca, datacube, inmet, mit-eddie, wjh12}...
 Mirror Systems, Inc.                                   ...mirror!prism!matt
-----------------------------------------------------------------------------