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

[David Froble]

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?