[Info-vax] C99 updates to CRTL

[John E. Malmberg]

On 7/29/2019 8:00 AM, John Reagan wrote:
> 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.

That is part of the "DEC C" swamp that needs to be maintained for a 
while with "DEC C".

Code changes are likely going to be needed for x86 and for Clang based 
compilers.  So no need to make the Clang based compilers bug compatible 
with the past sins of DECC.

Are the Clang based compilers being back ported to Alpha/Itanium?

If not, then customers would need to put conditionals in their source to 
support the older compilers, but eventually everything supported is 
going to Clang based, so it would be better if the ifndef __DECC section 
of customer code could be cleaner and just specify the VMS specific 
extensions.

While that may make it a little more painful to move source to Clang, in 
the longer term, that code will be easier to maintain.

Regards,
-john
wb8tyw at qsl.net_work