In order to get this to run properly under VMS, In
menu.c, the following changes were added to
WriteNEditDB and ReadNEditDB respectfully ( diff -u
output ) -- see uploaded file.
diff -u menu.c menuFixed.c
Logged In: YES
It should also be noted that this has not been tested with a
Unix platform - only VMS 7.3
Logged In: YES
Your fix for writing the history file appears flawed to me.
When a file is opened in "r+" mode and the new contents is
shorter than the old one, there will be some trailing
garbage in the file when it is closed. At least, that's what
happens on Unix.
For instance, suppose that the history file contains this line:
If you reopen the file in r+ mode, and insert a new entry
the net result will be a file containing this:
Isn't there a way to force file truncation on VMS?
Would "w+" work?
The conditional compilation statements should ensure that
this fix is not used under unix - it should appear unchanged
under unix, however, this was not tested. It would be no
surprise if the "r+" did not work under unix.
The code has been used daily since the fix - successfully.
The following from the DEC C run-time library manual for
OpenVMS might be useful:
"r+" opens an existing file for read update access. It is
opened for reading, positioned first at the beginning-of-file,
but writing is also allowed.
Contrast this with:
r+ open text file for update (reading and writing)
Tru64 UNIX Compaq C Language Reference Manual
It's not the behaviour on Unix that I'm afraid of; I know
it's compiled conditionally. Unix positions the file point
at the beginning also, BTW.
What I'm saying is that if the behaviour on VMS is the same
as on Unix, the file is not truncated, and this can result
in trailing garbage. This trailing garbage can eventually
show up as junk entries in the Open Previous menu (which you
may never have noticed, if they ever showed up at all).
VMS appears to have ftruncate(), so we can use that to force
truncation. So I would write the VMS part as follows:
if ((fp = fopen(fullName, "w")) == NULL)
if ((fp = fopen(fullName, "r+")) == NULL)
if (ftruncate(fullName, 0) != 0)
Do you see any problem with that?
Summary of private communication with roymac:
he confirmed that his suggested fix resulted in trailing
garbage in the history file, as I suspected. Adding an
ftruncate() call solved the problem. The fix is now in CVS.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.