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

[David Froble]

johnwallace4 at yahoo.co.uk wrote:
> 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?

Nope!

> 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.

If what one wants is *ix, then why not just use *ix?