VMS Specific question about binary reads using fgetc

[Bradford R. Daniels]

In article <7459 at ganymede.inmos.co.uk>, pauls at lion.inmos.co.uk (Paul
Sidnell) writes:
> My understanding (arrived at with much pain and frustration) is that
if a file
> already exists, the mode that you open the file in is ignored
> completely. If you
> delete the file and THEN fopen("filename","rb"); then a 'STREAM-LF' file
> will be
> created and everything will be happy again.

Huh? "rb" opens the file read only.  Of course the file will still have
whatever
attributes it had before it ws opened.

VAX C tries to balance Unix compatibility and VMS integration wherever
possible.  On Unix, opening an existing file whether for input or output
changes nothing about the file except the date and possibly its contents
(if you're truncating the file).  Other attributes (ownership, permissions,
etc.) remain unchanged.  The first implementors of the VAX C RTL decided
(quite reasonably, I feel) to extend that concept to the much larger set
of attributes files may have under VMS.  Thus, if you supercede an existing
file, it should (were it not for some bugs in certain code paths in the
RTL) have the same protection, format, carriage control, and whatever else
as the existing version of the file.

If you did not explicitly specify any file format or carriage control
options, the C RTL assumes you don't want to change anything.

> Similarly you will find many 'departures' from ANSII C using ftell and
fseek on
> non 'STREAM-LF' files.

Yeah, it kinda bugs me, too...  It actually would have been possible to get
better emulation for files smaller than 4MB if a different encoding had been
chosen from day 1, but the algorithm would have been completely broken for
larger files, and the values returned by ftell() would not have been simple
integer offsets from the beginning of the file.  As it is, the current
algorithm
is the best you can do given 32 bit integers and RMS' requirements.

> Generally, the I/O is at it's sanest ONLY on these types of files.

Actually, it's pretty sane on most file types if you know what it's supposed to
do.  The problem is a lack of documentation as to what it's supposed to do...

> Please excuse any froth around my mouth while I discuss this subject.

We've been looking over ways to improve the VAX C I/O system in a major way,
perhaps even rewriting the whole thing.  Constructive frothing is always
appreciated.

- Brad

-----------------------------------------------------------------
Brad Daniels			|  Digital Equipment Corp. almost
DEC Software Devo		|  definitely wouldn't approve of
"VAX C RTL Whipping Boy"	|  anything I say here...