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

[John Reagan]

On Thursday, June 30, 2016 at 2:07:54 AM UTC-4, David Froble wrote:
> 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.
> > 
> > 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.
> > 
> 
> I guess my question is, what would keep a customer that just absolutely cannot 
> change from continuing to run an old version of the language / compiler?  If 
> that are that limited, I'd guess there is no development, and no changes anyway.
> 
> You do have to move, forward, or backward, cause the world is moving and you 
> cannot stand still.

If they are on Itanium today, they must be using some "recent" compiler (not V4.anything).  And going to x86, the frontend is V7.4 vintage.