[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 9:54:57 PM UTC-4, David Froble wrote:
> John Reagan wrote:
> > On Thursday, September 8, 2016 at 3:44:19 PM UTC-4, David Froble wrote:
> 
> >> 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__ ?
> 
> If there is a problem, then it is a stupid problem.  I can allocate memory from 
> Macro-32, and deallocate it from Basic.  Or the opposite.  Or substitute any of 
> the VMS languages.  So what's the problem?  They are still using VMS services to 
> do the job, right?

As Steve said, there are abstractions above the calls to LIB$GET_VM and LIB$MALLOC.  You wouldn't expect to do a NEW in Pascal, pass the pointer to a C routine and do a free(), would you?  However, when it is the same language, you expect that to work regardless of the compiler used.  Do you want to mix DEC C objects and clang objects?  Given that we will only have clang++, it is a given that we'll have to let you mix DEC C objects with clang++ objects.  The line between C and C++ is fuzzy.  I think it is expected to malloc() in one and free() in the other.

On the other hand, you can't easily mix g++ and clang++ objects on a Linux box since there might be differences in vtables, etc.