[Info-vax] C99 updates to CRTL

[Stephen Hoffman]

On 2019-07-31 00:10:17 +0000, John Reagan said:

> To be honest, that logical [decc$crtlmap] is only designed to be used 
> as part of the CRTL build itself where I want the compiler to prefix 
> newly written routines that are not part of the build system's 
> installed CRTL.  It would never be used in the real world.


If there's a knob around, it'll inevitably accrue dependencies. Whether 
or not the knob is documented.

More than a few systems have it defined, as a way to select the target RTL.

Based on what I see around, that logical name is part of the mechanism 
used to allow the selection of the CRTL for Alpha processors with 
byte-word support (EV56 and later):
https://groups.google.com/d/msg/comp.os.vms/npJUbALe9Lo/GTFA_64eAAAJ

OpenVMS Alpha systems with the following definitions are common:
"DECC$CRTLMAP" = "SYS$SHARE:DECC$SHR_EV56"
"DECC$SHR" = "SYS$SHARE:DECC$SHR_EV56"

It wouldn't surprise me to see something similar to this mechanism 
return on some future x86-64 environment too, as newer instruction 
subsets arrive and become supported.

And it's been used in some customer app builds, and some going back 
over twenty years:
https://groups.google.com/d/msg/comp.os.vms/4FTyhZ3V4rk/eRiR1lLhbgIJ
http://www.sidhe.org/vmsperl/installfaq.html
http://de.openvms.org/martinv/VMS_Programming_FAQ.html
http://ftp.nd.rl.ac.uk/muon_restore.COM

The C environment on OpenVMS is thirty years of accretion, and—ignoring 
the ports—with the last substantial overhaul back at V4.0.  And to be 
clear, this isn't all that different from most of the other programming 
language environments on OpenVMS. Y'all have a whole lot of work ahead 
here of course, and with the next overhaul arriving with llvm/clang and 
(hopefully, eventually) a replacement/overhauled C11/C17/C18 library 
and compiler becoming available.  Because what we have now is looking a 
whole lot like VAX C once did.



-- 
Pure Personal Opinion | HoffmanLabs LLC