[Info-vax] decc$stat() variants on VMS.

[John Reagan]

On Wednesday, June 29, 2016 at 9:25:23 AM UTC-4, John E. Malmberg wrote:
> Since this is discussed on other threads.
> 
>  From looking at stat.h, it looks like there are at least 7 different 
> variants of stat() as of VMS 8.4 as Compile time options.
> 
> The standard stat() call is probably closest to Unix.  The main thing 
> about the others is that the dev_t returns a pointer to the VMS device 
> name for the file.
> 
> The standard stat returns a unique dev_t number for the device. 
> Unfortunately VMS does not provide the routines to parse the dev_t 
> number or translate it to an actual disk device.
> 
> Interestingly the non-standard stats() are the easiest way for a C 
> program to get the device name and fid of a file in order to use the 
> FID_TO_NAME service to simulate realpath().

stat() is one of the big areas of ancient backwards compatibility that clogs
up the CRTL.  Want me to just keep the standard version and toss the OpenVMS
specifics?  I'd like to get to a single stat() if possible but as you noted
standard stat() exposes some of the UNIX-y file system featuers with dev_t
and friends.  But I do want to cut some of the stat()s down even if I break
some folks.  Anybody want to add their 2cents?

> 
> The stat() call only returns the correct byte count for stream files.
> 
> For VMS text file formats, the only way to get the byte count seen by 
> reading the file is to actually read the file.  VMS ports of Curl now do 
> this in most cases.  While I have not seen a bug reported on this, I am 
> not certain port of Curl handles all cases of VMS text files everywhere.

I've avoided the lengthy discussion of what constitutes file size, meta-data vs real-data, etc.  So what does "size" really mean?  The number of bytes on the "disk"?  (what about disk subsystems that might compress or use some other cute scheme)  The number of bytes transferred into your memory buffer?  The number of bytes that contain useful data vs memory padding?  Even on UNIX, you can have mutliple utilities that process the same data.  One program only cares about every 10th byte, another program only cares about every 2nd byte.  How "big" is the file?  Even for EXE files (ignore your case about the partial block at the end - and there are RMS fields to let you get the byte count in that last block) there may be massive alignment holes in between the segments.  Does the file size of an ELF EXE file count those holes?  Does it count all the extra ELF junk scattered around?  In my opinion, the size of a file is the number of bytes it occupies on the storage medium (including RAM disk if so configured).  The fact that it might compress the data (ie, eliminate explicit line terminators in favor of using VAR_CR) or use simulate some terminal prompting feature by using FTN format or whatever is just one of those platform specific features.  So what if the number of bytes read back to the program doesn't quite add up to the number of blocks on the disk.

There.  I feel better now.