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

[Stephen Hoffman]

On 2015-03-14 03:16:57 +0000, Steven Schweda said:

>> 
>> BTW, you should be able to disable this inside the source
>> file by first checking the compiler version using __DECC_VER
>> then disabling the message.
> 
>    You seem to over-estimate my ability to persuade various
> keepers of open-source software to add piles of VMS-specific
> #pragma garbage to their source in order to work around such
> goofy behavior from a compiler on a system about which they
> typically care hardly a whit.  (And/or my willingness to
> try to explain why the difference between two 32-bit pointers
> should be a 64-bit entity.  I nearly wore out my welcome
> trying to deal with the not-NULL-terminated argv[] on Alpha
> with /POINTER_SIZE=64=ARGV.)  But thanks for the advice.

Ayup; it's a dumb default.  I'd rather see the crocks and hacks and the 
pain dispensed on the existing and crufty code, and not on the updated 
and correct and compatible code going forward.

Requiring workarounds — such as /FIRST_INCLUDE and pragmas — to get 
closer to what are now accepted practices and norms is not the right 
direction to go.

Sure, folks with old and busted and crufty code will not be happy with 
this in the short term (yeah, I know cha-ching!), but then they now 
have old and busted and crufty code, and they can use /FIRST_INCLUDE 
and pragmas and non-default qualifiers and the rest, while they move 
their crufty code forward to C11 and newer and safer and more 
industry-compatible source code practices, and while they remove and 
replace the unsafe C calls from their code.

I certainly wasn't fond of the work necessary to get upgraded to DEC C 
and ANSI C standards when all that first appeared, but ANSI C and the 
newer compilers are a whole lot better than K&R and the VAX C 
environment; what was replaced.  Cranking up the diagnostics, and 
deprecating the calls manually has made for better code.   Yes, based 
on recent threads, some folks are still working with K&R code, and it's 
a good bet that a number of their current problems and latent 
weirdnesses are directly attributable to /STANDARD=VAXC usage.   But 
y'all tried to get them forward.

Sooner or later, you need to deprecate and remove /STANDARD=VAXC, too.  
It's dead.

Don't cruft up the new source code environments and the new tools to 
keep source compatible with old and limited environments and tools.  
That does not end well.


-- 
Pure Personal Opinion | HoffmanLabs LLC