[Info-vax] C99 updates to CRTL

[John E. Malmberg]

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