[Info-vax] C and C++ and clanger-free clanging (was: Re: Porting to Linux instead of x86-64 VMS, ...)

[Neil Rieck]

On Wednesday, July 3, 2019 at 4:55:38 PM UTC-4, Neil Rieck wrote:
> On Wednesday, July 3, 2019 at 4:29:20 PM UTC-4, John Reagan wrote:
> > On Wednesday, July 3, 2019 at 1:54:44 PM UTC-4, Stephen Hoffman wrote:
> > > On 2019-07-03 16:15:42 +0000, John Reagan said:
> > > 
> > > > 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.
> > > 
> > > Okay, the phrasing here is somewhat ambiguous.  Are you referring to 
> > > making a syntax switch from DCL to a foreign-command, or are you 
> > > discussing the default compilation mode for C code invoking the C 
> > > compile absent a specific /STANDARD selection?
> > > 
> > > Absent a specific selection, the default standard was the newest, IIRC. 
> > >  That hasn't been tripping folks since shortly after 1999 and for what 
> > > should be obvious reasons, but there was an assumption that developers 
> > > would have to add switches to accept old and now-deprecated standards.  
> > > And I see no reason not to make C11 the default, if there's no C18 and 
> > > thus C11's the newest available.
> > > 
> > > That it's two separate compilers with two separate licenses has been 
> > > tripping new-to-OpenVMS developers for some time.
> > > 
> > > If it's around the compiler switches and changing from DCL parsing 
> > > syntax to clang's own switch syntax?    For those that don't want to do 
> > > that and just want to add a few, /CLANG="-Wall-Wextra -pedantic", 
> > > maybe.  But then I'll probably be dropping down to the clang command 
> > > line directly.  Which is where I think you're headed, if this is about 
> > > DCL command parsing and not about C standards and source code parsing...
> > > 
> > > > 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
> > > 
> > > Yeah, the Dr Dobb's article is a pretty good one.
> > > 
> > > Also see: 
> > > https://smartbear.com/blog/test-and-monitor/c11-a-new-c-standard-aiming-at-safer-programming/ 
> > > 
> > > 
> > > There's stuff there that I've been using else-platform.  Or 
> > > occasionally back-porting to OpenVMS.  Better support for turd files, 
> > > too.
> > > 
> > > Re-reading the C manuals every few years was handy, given what was 
> > > being added in the latter parts of V7 and into the early V8 range.
> > > 
> > > Getting threading integrated with KP threads and maybe also with 
> > > gcd/libdispatch and with the blocks/closures support would be nice.  
> > > Better threading than what is available.
> > > 
> > > 
> > > -- 
> > > Pure Personal Opinion | HoffmanLabs LLC
> > 
> > I was talking about the "syntax" clause in the .CLD file.  I'd like /STANDARD=C11 to invoke a different image.  I could make it really twisty and have the legacy VSI C compiler do a LIB$DO_COMMAND of clang-as-a-C11-compiler when /STAND=C11 is set.
> > 
> > The problem with that is that clang-as-a-C-compiler will never support lots of pragmas that the legacy C compiler does.  It seems too confusing to magically switch the compiler out from under you with a /STANDARD qualifier option.  I want to make it clear that asking for C11 means a different compiler.  If you want to move into the future (er, past) with C11, it means you have to let go of the legacy tree.  Of course, open source software coming to OpenVMS for the first time won't use any of those old DEC features.
> > 
> > For the CXX DCL interface to clang++, I don't see us providing an arbitrary /CLANG_OPTIONS="random string".  We'll provide a reasonable mapping for the existing DCL syntax for the "recompile-and-go" crowd.  We'll probably add some support for various common hardware flavors with /ARCH.  Maybe a few others.  But if you want to specific lots of strange exotic options, use the foreign command form.  That said, if you compile without -fPIC (and perhaps a few other ones), the object probably won't link/execute correctly.  In order to support shareable images, INSTALL/RESIDENT, etc., you must compile with -fPIC.  The DCL interface will set that for you.  We'll provide guidance when the time comes.
> 
> John, thanks for this info.
> 
> IMHO this is all very good news and I think I can speak for the whole OpenVMS community in saying that we don't need a Swiss army knife where everything is changeable from DCL (everyone here already knows that most modern compilers are used from within project managers, but I digress). But this community already needs one, or more, tools which will support current and future C/C++ standards. I could care less if this one one, or several image files. I probably don't need to mention the obvious: Any OS not supporting current and new versions of C/C++ is doomed to obsolescence.
> 
> p.s. let's keep this discussion going
> 
> Neil Rieck
> Waterloo, Ontario, Canada.

It's a funny thing about tool boxes. After a mechanic acquires socket wrenches he does not throw out the adjustable monkey wrench. I suppose many OpenVMS customers will want VSI to continue to support DEC-C and DEC-C++ though the DCL interface (eg. CLD) and, perhaps, those products might not need to support newer language standards. Customers requiring higher standards via the CLANG solution will probably need to do so via a redirected DCL symbol or VMS logical name.

Neil Rieck
Waterloo, Ontario, Canada.