[Info-vax] C99 updates to CRTL

[John Reagan]

On Monday, July 29, 2019 at 8:55:48 AM UTC-4, John E. Malmberg wrote:
> On 7/27/2019 3:56 PM, Craig A. Berry wrote:
> >  
> > As far as I know, the only reason to guard a function's prototype with
> > _ANSI_C_SOURCE is if you offer two different implementations of it, one
> > of which conflicts with the standard one.  Arguably this isn't even
> > necessary for the stdio functions with the RMS options because those
> > don't *conflict* with the standard, they just extend it with optional
> > arguments; a standard-compliant call would still work as-is.  But I know
> > the ship has long since sailed on those.
> 
> The stdio extensions do cause problems with porting, they cause problems 
> with trying to use gnulib and with gnu configure scripts.
> 
> While that ship has sailed for "DEC C", for a new compiler I would 
> strongly recommend:
> 
> All (DEC/VSI) extensions to the standard have their own uniquely named 
> routines.
> 
> All (DEC/VSI) extensions to the standard have their own header files.
> 
> And a notification to customers that the bugs fixed in the VMS 
> implementation of standard routines will have the fixed behavior be the 
> default entry point to the library for that routine.
> 
> The above may require a way of having a customer use an older shared 
> library for a specific image if their binaries depend on a buggy behavior.
> 
> Take the opportunity to drain the swamp a bit.
> 
> So if a customer wants to use the new compiler, they may need to make 
> some source code changes to make their code work to the standard, 
> otherwise they can stay with the old standard.
> 
> Regards,
> -John
> wb8tyw at qsl.net_work

That is hard to do in a mixed arch cluster of Alpha/Itanium/x86.  I already received feedback from a customer who now has to "undo" all their workarounds for things that now have appeared in stdint/inttypes.  They didn't guard with an "ifndef" 20 years ago.