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

[Stephen Hoffman]

On 2016-06-29 17:29:42 +0000, John Reagan said:

> 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?

Nuke^Wdeprecate the whole mound, replace it with flat 64-bit, and move 
on.  You're *never* going to be able to remediate a couple of decades' 
accumulated cruft^Wcompatibility.  *Never*.   Not without breaking 
something else dependent on the existing bugs^Wbehavior, and not 
without further degrading the existing code into yet denser thickets of 
cruft^Wconditional compilation.

Give folks something to move forward to, and to look forward to.   When 
you have to make a choice, make that trade-off facing forward.   Not 
backward.  Preferably — with C — toward C11 and POSIX and better 
compatibility.  (Going toward OO APIs is probably a bridge too far, 
though.)

> 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.

What I wrote out.   What the OS then did with it — compression, 
chunking it into sectors, sector- or file-level de-duplication, 
whatever — is NMP.   If I have to deal with padding, sectors, allocated 
storage, de-dup'd size or whatever, then I'm writing OS code, and I 
probably should use OS code — lib$rename or rename() or lib$delete or 
remove() or whatever — to deal with that, or have a look at the blocks 
allocated.

The following is a stat.h structure from the local box:
...
         off_t           st_size;          /* file size, in bytes */
         blkcnt_t        st_blocks;        /* blocks allocated for file */
         blksize_t       st_blksize;       /* optimal blocksize for I/O */
...

> 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.

Yeah, and IIRC CMS used to (maybe still does?) store data after the 
EOF.   That hosed a few tools.


-- 
Pure Personal Opinion | HoffmanLabs LLC