[Info-vax] Porting to Linux instead of x86-64 VMS, was: Re: 3rd party SATA SSD usage on RX2660+P400 in a production environment?

[John Reagan]

On Wednesday, July 3, 2019 at 10:21:24 AM UTC-4, Neil Rieck wrote:
> On Wednesday, July 3, 2019 at 8:46:56 AM UTC-4, John Reagan wrote:
> > On Wednesday, July 3, 2019 at 7:43:12 AM UTC-4, Neil Rieck wrote:
> > > On Tuesday, July 2, 2019 at 1:22:47 PM UTC-4, Simon Clubley wrote:
> > > > On 2019-07-02, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> > > > >
> > > > > And in two or three years, we'll either be starting to replace these 
> > > > > existing servers with x86-64 and ports to that, or we'll be starting up 
> > > > > the Linux ports again.
> > > > >
> > > > 
> > > > Are people actually talking about doing the latter ?
> > > > 
> > > > If so, is this due to the current VMS on x86-64 timescales or is
> > > > it due to some lack of information coming out of VSI ?
> > > > 
> > > > If it's the latter, is there anything VSI can do at the moment to
> > > > give both management and technical customer employees more confidence
> > > > in the future of VMS ?
> > > > 
> > > > Simon.
> > > > 
> > > > -- 
> > > > Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> > > > Microsoft: Bringing you 1980s technology to a 21st century world
> > > 
> > > IMHO, the thing that will slow the adoption of new software on OpenVMS is the tool set. And here I am talking about VMS-C and VMS-C++ which do not yet support the C11 or C18 standards. For example, I have heard from several people that both MySQL and MariaDB applications after version 5 require C11.
> > > 
> > > I have been told that VSI is aware of this and is working on C11 as we speak. This whole problem was caused by HP (now HPE) who decided to let this fruit die on the vine.
> > > 
> > > Neil Rieck
> > > Waterloo, Ontario, Canada.
> > > http://neilrieck.net
> > 
> > Uh, are you confusing C11 with C++11?
> > 
> > https://mysqlserverteam.com/mysql-8-0-source-code-improvements/
> 
> IMHO, the Linux community is responsible for most of the confusion. While most of the world correctly treats C and C++ as separate languages, the "gcc" and "c++" commands on most Linux platforms pull up the same application. Check this out on one of my fully-patched CentOS-7 systems:
> 
> [neil at kawc4n ~]$ gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
> Copyright (C) 2015 Free Software Foundation, Inc.
> 
> [neil at kawc4n ~]$ g++ --version
> g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
> Copyright (C) 2015 Free Software Foundation, Inc.
> 
> To complicate things further, for quite some time now, "gcc" has meant "gnu compiler collection" rather than "gnu c compiler" although I continually hear people use "gnu c compiler" at local IEEE meetings. (coffee shops; not formal speech from the lectern)
> 
> Anyway, changes have been made to both C and C++ which (it is claimed) cause both these compilers to generate safer executables provided the developer is compiling with those extensions enabled. Ditching the "gets()" i/o function seemed like a good idea since it is the source of many exploits. I am also intrigued by the promise of (optionally) including bounds checking to arrays. (I have only mentioned two changes of many).
> 
> Anyway, the OpenVMS community is now in this dilemma because HP didn't want to further develop the DEC-C and DEC-C++ compilers so now we've got a problem: open source programs developed in "that other larger ecosystem" are no longer "easily" ported to OpenVMS. 
> 
> Anyway, I have 100% confidence in VSI modernizing VSI-C and VSI-C++ because both C/C++ will continue to evolve (The C standard seems to change every ~ 10 years whilst C++ standard seems to change every 3 years). Whether we like it or not, these two languages are the most important languages on the planet today.   
> 
> Neil Rieck
> Waterloo, Ontario, Canada.

clang is one application but depending on the command line, it behaves quite differently.  Same with "gcc" vs "g++".  Even in OpenVMS, SUBMIT and PRINT use the same image but have very different qualifiers.  Sometimes programs check "argv[0]" and their image names or some hidden qualifier passed from the driver program.

clang is a self-driver.  clang is a "driver", "C++ compiler", "C compiler", and an "Objective C compiler".

For OpenVMS x86 9.1/9.2, the "CXX" DCL command will invoke clang with the "you are a C++ compiler" option with the "and please accept C++17 code".  The "CC" command will invoke the traditional [DEC|HP] C compiler which is C99, not C11.  Recompile-and-go and all that.

Beyond that, I can't do a DCL "syntax" change on /STANDARD=C11.  I could try something like "CC/CLANG" or "CC/C11" that would turn around an attempt to invoke clang with the "you are a C compiler and accept C11 code" but I find that ugly.  My current plan is say "invoke SYS$SYSTEM:CLANG.EXE" (or whatever we decide on the final name) as a DCL foreign command.

$ clang :== $sys$system:clang.exe

and now you should be able to invoke clang with any of the 500+ command line options that the clang driver knows about.  One of those is "you are a C compiler".

My experience is that most people care about newer C++ standards, not about C11 or C18.  The only C11 feature I've been asked about is "static_assert".  I'd be willing to cherry-pick that one and put that into our C frontend.  Most of C11 is atomic and threading which can be done with C++.

For a good description, read:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3631.pdf