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

[johnwallace4 at yahoo.co.uk]

On Saturday, 10 September 2016 02:13:01 UTC+1, David Froble  wrote:
> John Reagan wrote:
> > 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.
> 
> Personal opinion.
> 
> I think that when you implement an environment on top of another environment, 
> then you're no longer really running executables under the lower (not sure what 
> term) environment.  In this case, if special stuff is implemented in C, then by 
> using it you're no longer running on VMS.
> 
> I also think that if you're going to claim that you're running executables on 
> VMS, then it should always be VMS services used to do things, not some language 
> specific replacement of a VMS service.
> 
> But what do I know ???

I guess you weren't a fan of VMS POSIX then?

If it had lasted, if the customers who said they wanted open standards
had walked the walk as well as talked the talk, many of the "porting"
and "tools" issues being discussed round here would have been non-issues.