[Info-vax] C99 stuff (Re: The Road to V9.0)

[John Reagan]

On Friday, June 7, 2019 at 11:31:14 AM UTC-4, Stephen Hoffman wrote:
> On 2019-06-07 15:10:08 +0000, John Reagan said:
> 
> > On Friday, June 7, 2019 at 10:26:42 AM UTC-4, Stephen Hoffman wrote:
> >> On 2019-06-06 23:44:44 +0000, Steven Schweda said:
> >> 
> >>>> 
> >>>> [...] I get tired of dragging around my own home-grown versions of stdint.h
> >>> 
> >>> I know the feeling.  Is there any chance of a C macro in some place 
> >>> like <inttypes.h> or <[decc$]types.h> (or somewhere) which would reveal 
> >>> the existence of <stdint.h> at compile time?  Or will some __DECC_VER 
> >>> value be the clue?
> >> 
> >> I'd hope it'd be the expected __STDC_VERSION__ >= 199901L for this 
> >> check, but that ship may well have already sailed.
> >> 
> >> The compiler itself has been C99 since the ~millennium.
> >> 
> >> It's been the RTL and the headers that have lagged C99.
> >> 
> >> And as I've suggested before, I'd prefer to make the folks that don't 
> >> want to update their code have to take some minor steps—setting some 
> >> system parameter, tweaking a compiler CLD, defining some logical name 
> >> (gag), whatever other LTS-enable scheme—to re-establish the old 
> >> defaults for the old and unmodified compilations, and leave the 
> >> defaults to be the most current compiler support available.  Drag this 
> >> old mess forward best speed, and don't make those of us that are 
> >> maintaining and updating our code pay extra and forever, versus not 
> >> making the folks that aren't maintaining and updating pay even a little 
> >> bit just once.
> > 
> > This isn't just "define a few new symbols/macros" that can be guarded 
> > (at least without making the headers even uglier).  <inttypes.h> comes 
> > with C99 as does <stdint.h>.  Any inclusion of <inttypes.h> (at least 
> > to me) is the confirmation that you want the C99 names added to your 
> > namespace.  We just didn't do all of them in the past.  We do now.  
> > Don't want C99 names?  Don't include C99 headers.  No different than 
> > any Linux box.  Putting "-ansi" on gcc doesn't keep you from shooting 
> > yourself in the foot with an include of <inttypes.h> or <stdint.h>.
> 
> So long as it's C99 and works like C99 and has C99 functions and 
> headers and I don't have to drag along my existing baggage to make the 
> environment more C99-ish, that's fine.
> 
> I can and do expect to have to hack out my existing C99-ish baggage.
> 
> But I don't want to have to special-case builds for new development to 
> select C99.  Or similarly, to eventually special-case to select C11 or 
> C18.  __STDC_VERSION__ >= 199901L or whatever, and off I go.
> 
> For the folks that need to stay on C89/C90 and for whatever reason, 
> provide a way to allow the compiler invocation to select that, if there 
> are to be source or build-incompatible changes.
> 
> Make the folks that want/need compatibility do some work, rather than 
> foisting that complexity off on the rest of us that are updating.
> 
> Make the defaults the most current.  Not the oldest and the roughest.
> 
> I'd prefer y'all deprecate the existing rats-nest of headers too, and 
> force a migration to modern headers.  Keep the old headers around 
> somewhere and for a while and maybe the old RTL if that too gets 
> trashed, and let folks modify their environments to use those.  Prolly 
> with the arrival of x86-64 and Clang, there.
> 
> Default to the most current C available.
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

For "classic" DEC C frontend, C99 is the latest (and final unless we cherry pick something from C11 like static_assert).  For real C11 and later (such code almost certainly is coming from the open source world and does not have legacy OpenVMS VAXC-isms in it), our long term goal is to invoke clang in C11-mode.  We'll end up with two C compilers: DEC C and clang-as-C.  

For clang as the C++ compiler, the default will be whatever clang++ currently defaults to.  Until recently, clang++ defaulted to C++11, but a recent change might have bumped that to C++14.  clang++ itself has full C++17 support (and even some early C++20 support but that standard hasn't been completed yet).  

We'll extend the clang++ driver to handle the CXX DCL command map the current qualifiers to something reasonable.  We'll change the default for /STANDARD and scrub off a few values as well.  And we'll also let you define "clang" as a foreign command and invoke it with its standard Linux command and all possible options (over 500 options last time I saw a count).  We won't be able to test them all or even support them all, but we'll give you all the rope you'd like.