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

[John Reagan]

On Wednesday, June 29, 2016 at 10:29:38 PM UTC-4, Craig A. Berry wrote:
> 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.
> 

That's my view at this point.  You won't need _DECC_V4_SOURCE on x86 or
even Itanium since V4 compilers don't exist on those platforms.

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