[Info-vax] General Availability of 9.2 for x86-64

[Jake Hamby]

On Friday, July 15, 2022 at 11:02:30 AM UTC-7, Simon Clubley wrote:
> On 2022-07-15, VAXman- @SendSpamHere.ORG <VAX... at SendSpamHere.ORG> wrote: 
> > 
> > There are hundreds of thousands of lines of Macro32 in just the code that 
> > I maintain for several third-party applications. In this day and age, it 
> > is highly doubtful that the companies which own these products would pay 
> > me to recode it all in your beloved C language and then, go through all of 
> > the effort to verify that the rewritten code still performs like the old. 
> > I think there was another company that put forth that same argument. If 
> > ONLY I could only DECant its name from my vast recollection. 
> >
> C isn't beloved by me Brian. It is however the most practical and viable 
> language to use in a wide range of applications unfortunately. 
> 
> As I have made clear _many_ times, I wish something from the Wirth side 
> of the language ecosystem had become established as a standard and viable 
> alternative to C. Unfortunately, I have to work with what is available 
> and viable, not what I would like to use in an ideal world.
> Simon. 

I agree with Simon. It's best to think of C as the de facto generic assembly language, except with a worse macro processor than most macro assemblers (including VAX). If your code is well-structured, then it's far more maintainable than when it's not.

My current hobby project is updating the GNV port of bash to, among other features, support real subshells using vfork()/exec() instead of faking out vfork() by saving/restoring the bash state. That requires me to bundle up the state of the parent shell and send it to the child to unflatten in its own memory space. So far I've found that the spaghetti nature of 120,000+ lines of K&R C code with 500+ global variables is nearly as bad as deciphering poorly-structured assembly language, except for the productivity boost of VS Code's outline view (which required me to convert the function prototypes from K&R to ANSI C, because their parser understandably got confused by the K&R prototypes).

Without the outline view, it's easy to miss two or three global variables defined in the middle of the .c file between function definitions, all with the same naming style. I was trying to use vim alone and it just wasn't working. I couldn't keep the entire file in my head at once. I think it's mostly GNU bash's fault for taking on 30 years of technical debt in their codebase, but also partly the fault of the C language for allowing such sloppiness. If they'd written it in Ada 83, they would've at least had package specs and package bodies. Based on some code comments, the original GNU authors were mad that they couldn't write it in Lisp.

The most useful VMS update for me has been the C99 support added in the RTL patch for Alpha and Itanium. It was really demoralizing not to have at least <stdint.h> and the other header files, even though the C compiler supported nearly all of the language features, and it feels funny to suddenly get that support after so many years of not having C99. I don't "love" C99/C11, but they sure beat what came before. And I'll be really happy when I get to use the LLVM C++ compiler on VMS.

Jake