[Info-vax] September 6, 2016 - new Roadmap and State of the Port updates now on VSI website

[John Reagan]

On Thursday, September 8, 2016 at 3:44:19 PM UTC-4, David Froble wrote:
> Stephen Hoffman wrote:
> > On 2016-09-08 16:13:43 +0000, Craig A. Berry said:
> > 
> >> ...While SSIO is important for some use cases, they aren't the ones 
> >> I've run into personally. I would rather see a decent pipe() 
> >> implementation in the CRTL.
> >>
> >> SSIO will likely involve looking at how I/O is done in the CRTL more 
> >> generally and how it could be done better. For example, is $IO_PERFORM 
> >> used where it can be, or is everything still using $QIO or RMS?
> > 
> > The C I/O implementation on OpenVMS is (necessarily) a morass of 
> > compromise, compatibility with how OpenVMS works, standards compliance 
> > and conflicts with how OpenVMS works.
> > 
> > All those logical name knobs are areas the developers didn't want to 
> > break compatibility; an exit or an out from one of the (many) decisions 
> > involved.
> > 
> > Even the logical name knobs are themselves a compromise; to avoid 
> > increasing the scope of the work with a more generic and more integrated 
> > solution.
> > 
> > It's still seems odd that the C implementation on OpenVMS doesn't have 
> > better descriptor support baked in, too.  It's all structs and 
> > includes.  Which works.  But makes for reams of glue code.
> > 
> > There's no right answer here, and meeting the expectations of the 
> > OpenVMS-native crowd and the portable C crowd can easily end up in 
> > conflict.
> > 
> > I'd really prefer to see somebody look at the whole environment — C, and 
> > then the CLE and beyond — and try to find better designs, and start 
> > moving in that direction.
> > 
> > Toward 2021 and 2026.  Not (blindly) preserving designs and decisions 
> > and compromises and trade-offs made in years past.
> > 
> > 
> > 
> 
> Ok, I'll throw out an idea here.  Not saying it's a good idea, and I'm sure 
> Steve won't like it.  Well, pretty sure.
> 
> How about two C compilers on VMS?  One for VMS users, and one aimed at porting 
> needs.
> 
> I'd assume that they would be almost identical,so common code could be used in 
> the compilers.  Don't know how difficult this would be.  Most likely a John 
> Reagan question.
> 
> Not saying leave either of them in the past.  Both should be kept current, and 
> mostly logical name free.  Just saying, if what's needed for porting *ix snake 
> oil just isn't compatable with more traditional VMS users, then face up to the 
> issue and address it in some workable manner.

That's basically what you are getting.  The DEC C frontend hooked to LLVM gets you the C99 compiler with all of the strangeness that you want (there will probably be some things changing/disappearing - #pragma linkage for example).  I don't see that compiler getting any C11, etc features.

And then you have clang (which is several compilers rolled into one).  That compiler has all the standard's compliance you want but currently none of the OpenVMS extensions you want.  That is what we'll be doing.  We'll try to limit the changes to the smallest set possible.

Do you mix objects from both compilers?  Yes from the calling standard point of view, but they often contain calls into the RTL. Do the compilers share the same CRTL?  Can you malloc() in one and free() in the other?  Can you fopen() in one, but fclose() in the other.  Are the "errno"s the same or not?  If you pick up C11 headers, etc. do you let them work in the DEC C case?  Or is that just __STDC_NO_THREADS__ ?