[Info-vax] C99 updates to CRTL

[Stephen Hoffman]

On 2019-07-30 15:12:19 +0000, Dave Froble said:

> On 7/30/2019 9:58 AM, Stephen Hoffman wrote:
>> App management and configuration with logical names—other than for 
>> device redirection, and that usage is only marginally better than app 
>> config data—is among the more fetid coding practices and endemic on 
>> OpenVMS.
> 
> The "logical name" rant is usually interesting.  But, this time, I 
> wondered just how "guilty" I've been.  So I took a look.
> 
> I use logical names to refer to mailbox names, which gives me a defined 
> name for something that will usually (always) have a unique name each 
> time the mailbox is set up.

Some of those are forced by the APIs, and which is why I mentioned 
device redirection.

OpenVMS tries to make that practice somewhat less exploitable, too. But 
there are likely still exploitable cases.  There are certainly 
surprises, given users can directly modify logical names, and make 
typos or can deliberately introduce errors.  OpenVMS has gotten itself 
in trouble with logical names from time to time.  Here's a very old 
example of that: https://www.netfunny.com/rhf/jokes/89q4/evild.693.html 
 There've been other examples. Keeping that stuff packaged together 
with the app, and providing a parser cuts down on the surprises.

> I use logical names to refer to devices, such as disk drives, the 
> printer LTA port, MODEM_PORT (old cruft no longer used), and such.

Logical name cruft builds up, too.  It can be scattered all over the 
app source code, and all over the app documentation, and often ends up 
scattered around user startup procedures, too.  And different systems 
near-inevitably drift apart. Different logical names, different modes, 
different settings.

> There is a few telling the linker where to look for object libraries, 
> RTLs, and a few telling the compiler where to look for object libraries.

Again, those are forced by the APIs.

I'm working with build environments and tooling that don't need that 
baggage, but that's not the sort of thing I expect to see in widespread 
use on OpenVMS anytime soon. Use of bespoke DCL build procedures, or of 
a make tool, is just too entrenched.  And for various cases, necessary.

> Now we all know Dave doesn't get out much, but even so, I feel the 
> logical name capability is a good match for the above uses.  Not sure 
> what else would be better.
> 
> As for configuration data and such, I've never considered using logical 
> names for such, and probably would disapprove when I do see such.

You might not...  But logical name (mis)use for configuration data is 
all over the place, unfortunately.

Logical names are a good design from the 1980s.  But they're 
not-all-that-great and entirely volatile and scattered-around as a 
key-value store. Of limited usefulness for app configuration data, 
particularly given the limits of the common usage.

Ponder having all your settings for your app set-up and your app 
run-time all in one or two app-associated configuration files, with an 
API that you can query to read and potentially write settings, and with 
a provided parser that provides syntax-checking, and allows reading 
back configuration data in the app-required formats. And with tooling 
and user commands that allowed end-users and app developers to read and 
write settings.  This rather than having it-works-ship-it logical names 
and definitions and translations splattered all over the place.

One of the hold-my-nose cases I've used in recent times is a run-time 
debugging logical name, which can be used to enable additional logging 
without having to deploy a debug build into the problematic 
environment. That'd work from a configuration file, too.

OpenVMS has a number of years to go, if there's to be a goal of 
isolating and sandboxing applications and their related settings.  And 
isolating the potential damage.  Configuration data, digital 
signatures, licenses, they're all going to be related to that effort, 
too.


-- 
Pure Personal Opinion | HoffmanLabs LLC