[Info-vax] c 7.3 - Why MAYLOSEDATA3 for long pointer math?

[Stephen Hoffman]

On 2015-03-13 15:18:53 +0000, John Reagan said:

> On Friday, March 13, 2015 at 11:11:28 AM UTC-4, Craig A. Berry wrote:
> 
>> I think John was describing a decision made in the Compaq era or
>> thereabouts. I believe I've heard him say (not necessarily here) that
>> LP64 is on the VSI to-do list somewhere. I wonder whether LLP64 might be
>> better than LP64 for backward compatibility of structs, etc.; that's
>> what Windows did and has its advantages and disadvantages.
> 
> Yep, LP64 might be nice for a Linux program, but it might break 
> existing code (which is why I wouldn't ever change the default).  When 
> we get around to some LP64 work, adding the companion LLP64 (which is 
> what you get mostly today with /POINTER_SIZE=64 other than the 
> ptrdiff_t/size_t changes) companion setting probably isn't much worse 
> since we'd already be down in the ditches with shovels in hand.

I'd probably use that ditch and those shovels to utterly bury the 
existing mess, doing to DEC C what was done to VAX C back in the last 
millennia.  Use a couple of truckloads of concrete poured over the top, 
just to be sure the carcass^Wcompiler stays dead and buried.  Or in 
more politic terms, do the absolute minimum to keep the old compiler 
working.  Leave the existing compiler and the existing customer source 
code in the existing quagmire, and provide and encourage folks to 
migrate over to a newer and more consistent and less 
legacy-compatibility constrained configuration.

This current mess certainly looks to be the inevitable result of 
working to provide forever-compatibility combined with the engineering 
expediencies inherently involved with hacking together a specific 
solution in a specific area, rather than addressing the more general 
problem in a uniform and consistent way (and then incrementally 
migrating the pieces and parts over to the architected solution), after 
all.

I care rather less around absolute source-level compatibility here and 
long-term-compatible defaults than some other folks, particularly if 
the new platform or new framework or new tool — whatever is causing you 
to look to break specific source compatibility — provides substantially 
better features and capabilities, and where the changes I must make to 
the code correspond to improving the code or to upgrading what the 
application can provide the customers, or making the environment easier 
to manage, or some other non-trivial improvement, and where I can have 
some sort of a schedule for the deprecation of the older mechanisms the 
older code was using.

For this case, some reasonable set of pragmas and associated 
compatibility, but added into a wholly new compiler with most or all of 
C11.

Give third-party providers and existing customers and new customers 
good reasons to upgrade, and they will.  Customers that stand on older 
releases can and do have their reasons — they're the customers that 
were.  But don't let those folks hold back OpenVMS and its tools for 
those customers that are upgrading.  These are the customers that are, 
and these are the features for the customers that will be.


-- 
Pure Personal Opinion | HoffmanLabs LLC