PAWKA@nosc-tecr.ARPA (Pawka) (05/04/85)
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@NOSC-TECR.ARPA This gets old, you pay $X00.00 for these programs, they come with a disclaimer of any responsibility for any warranties, and they're full of bugs. Then you read on the net, "I can't see why anyone would pirate software"!! Phew, I feel better already.... ------
matt@prism.UUCP (05/10/85)
/**** 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@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
-----------------------------------------------------------------------------