[Info-vax] C99 updates to CRTL

[John Reagan]

On Monday, July 29, 2019 at 9:23:20 AM UTC-4, John E. Malmberg wrote:
> 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.
> 
We're not adding any "bugs" to clang. :)

We will be adding the minimal support to make it VMS-friendly (DCL command line, various pragmas, dual-sized pointers, etc.).  No /STAND=VAXC.  

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

LLVM does not have Itanium or Alpha targets.  We have no plans to write an LLVM IR to GEM IR converter to attempt to put clang on older platforms.  There would be massive backwards compatibility issues with the clang STL and the ones on the current platforms.  I suspect we'd have to invalidate all known C++ code.

> 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

I'm talking about "clang as the C++ compiler", not "clang as the C compiler".  Our traditional DEC C frontend will remain the default C compiler for the foreseable future.  However, they all share headers so our headers will have to guard appropriately for DEC C things.  Trying to use "clang as the C compiler" will indeed force people to scrub their code with a stiff wire brush.

Open source code coming TO OpenVMS doesn't have any DEC C extensions in it.  Exiting C++ code on OpenVMS Itanium should be pretty clean with just minimal changes around OS specific code.