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

[Craig A. Berry]

On 6/29/16 2:50 PM, Stephen Hoffman wrote:
> 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.

Yeah, but you have to try. There are two ways to do it that are
definitely wrong. One is to add layer upon layer of backward
compatibility without ever deprecating and removing dead code so that
you end up with mountains of technical debt (more or less what we have
now). The other is to break with the past so abruptly that existing
users have no reason to upgrade or even stay with your product.

Ideally there would be regular releases with deprecation announcements
that have some teeth in them. For example, not just deprecating VAXC,
but announcing a specific lifetime for the /STANDARD=VAXC compatibility
qualifier on DECC (a lifetime that should have come and gone by now). I
don't think OpenVMS Engineering has ever had this sort of thing as part
of the core culture, and all the institutional dislocations and
disruptions of the last decade have certainly not helped. But continuous
refactoring and steady deprecations where necessary is how it's done
now. That does require copious automated tests so you know where you
stand when you scrape off the barnacles.

For the 7 flavors of stat(), try to reduce that to 2 or 3, then further
simplify in a subsequent release. Some things in the CRTL should be
fairly easy to jettison; I'm not sure why we need _DECC_V4_SOURCE now
when v4.x of the compiler hasn't been current for a couple of decades.

It's far from easy to maintain a predictable sliding window of new
features and deprecations, but it's the right way to do it. It's what
the competition does.