jso@edison.GE.COM (John Owens) (08/28/86)
This message is being forwarded for a friend at a DECNet node.
Send all replies to me and I will forward them on to her.
John Owens General Electric Company - Charlottesville, VA
jso@edison.GE.COM old arpa: jso%edison.GE.COM@seismo.CSS.GOV
+1 804 978 5726 old uucp: {seismo,decuac,houxm,calma}!edison!jso
========================================================================
08/26/86 Libby Carpenter
- This problem was discovered on the microvax -
When creating text files that are used and input to VAX utilities, such as
the C compiler or macro assembler, we have been told by DEC S/W support to
avoid "fprint" and "fwrite" and to use just "write" instead.
What is the story with this??
They are running VMS v4.4 and C v2.1 and have tried C v2.2 with same results.
Analyze/rms shows the file as corrupted.
With version 2.x of C the way they handle writes have been changed.
Temporary fix is to have the new line character as the last char. of the last
write of the last line of the file.LEICHTER-JERRY@YALE.ARPA (08/29/86)
...
When creating text files that are used and input to VAX utilities, such as
the C compiler or macro assembler, we have been told by DEC S/W support to
avoid "fprint" and "fwrite" and to use just "write" instead....
They are running VMS v4.4 and C v2.1 and have tried C v2.2 with same
results. Analyze/rms shows the file as corrupted....
Temporary fix is to have the new line character as the last char. of the
last write of the last line of the file.
Since the problem statement only indicates a workaround, and no indication of
what was observed, it's hard to be certain; but this is almost surely a
previously-reported (and SPR'ed) problem that Gnu Emacs, among others, has
run into trouble with: RMS cannot deal with a STREAM_LF file that does not
have a trailing LF (C '\n') character. The symptom seen is RMS bugchecks
when the file is read. (RMS bugchecks are non-fatal from the system's point
of view, but usually blow away the user's process with no message. You can
check the accounting entry for the process and look at its final status to
see what happened.)
Anyway, it's an RMS problem, not a C problem, and will be fixed "in a future
release of VMS". In the meantime, there are at least two work-arounds:
Don't use STREAM_LF files. With V2.x of VAX C, the fopen() (and
open() and all related) function(s) allow you to specify the attri-
butes of the file being created. Use "rfm=var" and "rat=cr" (variable
length records, carriage return control) to get a "plain vanilla"
text file. Every program will accept these files; some may have
problems with stream files. The only limitation is that you can't
do arbitrary fseek's in such files - you can only seek to the begin-
ning of records. In my experience, very few applications need this
anyway.
If you need to do arbitrary seeks, just make sure to write a LF at
the end of your last record.
Either of these should be pretty easy to fit into existing code.
BTW, as far as I can tell, the use of "write" rather than "fprint" or "fwrite"
should have no bearing on this problem.
-- Jerry
-------