Lattice \"C\" Problem
matt at prism.UUCP
matt at prism.UUCP
Sat May 11 03:35:00 AEST 1985
/**** 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
-----------------------------------------------------------------------------
More information about the Comp.lang.c
mailing list