[Info-vax] Hard links on VMS ODS5 disks

[Dan Cross]

In article <u9bag8$2n8ej$1 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>[snip]
>> As for "easier, quick, robust", that's a matter of skill.   The real benefits
>> of C over BLISS/MACRO include "floating point" and provided I/O package.
>
>No, the real benefits of C include the ability to use abstractions in
>your code which make the code a lot quicker to write, where you can
>focus much more on what you want, instead of having to lay out in
>minute detail how to do it, and as a result your code also becomes
>much more reusable and portable.
>
>You can design complex data structures much more easily and get much
>more help from the compiler in finding errors in your code.
>
>For one really simple example, in C, you ask for a pointer and let the
>compiler implement the pointer behind the scenes. Ie: you write:
>
>	char *ptr;
>
>instead of:
>
>	uint32_t ptr;
>
>In C, your normal application code works the same, regardless of whether
>that pointer is 32-bits or 64-bits.

I don't know that I agree with this.

C is not a low-level language (seriously; it hasn't been for a
while: https://queue.acm.org/detail.cfm?id=3212479), but neither
is it a particularly high-level language.

And while, yes, there is a notion of pointer types as first
class objects built into the language, C programmers also pull a
lot of tricks like punning integers for pointers, and so forth
that make this fraught.

There are a few typedefs in e.g. <stdint.h> that can help out
here (`uintptr_t` and friends) but the language allows implicit,
lossy conversions and C code is often not as portable as one
would like to believe.

Moreover, in the past few decades, C _compilers_ have become
inhospitable to systems programmers, so much so that it is now
de facto impossible to write an OS kernel in well-defined C
code; that is, in C that doesn't invoke undefined behavior.
This, in turn, leads to needing lots of compiler-specific help
to force specific behaviors for these instances of UB
(https://arxiv.org/pdf/2201.07845.pdf).

>If the lowest-level language in VMS
>was C, this is what the RMS interface would conceptually look like:
>
>	struct {whatever}_rms_rab_t *rab;
>
>instead of the current setup. Likewise for itemlists and other structures.
>
>Things which are currently highly visible to the source code become
>abstracted implementation details that normal source code simply doesn't
>care about or have to deal with.

It's certainly easier to think of C as a high(er) level macro
assembler, but whether or not that's a good mental model is
debateable.  Personally, I wouldn't put a lot of new C code into
a kernel that wasn't already implemented in C post about 2018 or
so.

	- Dan C.