From: Peter@Iron-Spring.com   
      
   On 1/6/26 08:15, Lars Poulsen wrote:   
   > [Note Followup-To]   
   >   
   > On 2026-01-06, Carlos E.R.  wrote:   
   >> My C teacher said it was a mistake to use C as an all purpose language,   
   >> like for userland applications. Using C is the cause of many bugs that a   
   >> proper language would catch.   
   >>   
   >> That was around 1991.   
   >>   
   >> He knew. He participated in some study tasked by the Canadian government   
   >> to study C compilers, but he could not talk about what they wrote.   
   >   
   > I agree that C does the job reasonably well, and it is simple.   
   > And so, like most other geeks my age, I write with the tools I   
   > have used in forever, rather than spending my time learning new   
   > tools. For me, those tools are:   
   >   - C   
   >   - vim   
   >   - perl   
   >   - HTML (1.0)   
   > And yes, it is like using a vintage Jeep for a daily driver.   
   >   
   > The most egregious problem with old C is string handling.   
   > A useful "string" type would have   
   > - a maximum length, using hardware (exception) bounds checking.   
   >    to be useful, this would mean a length field in front of   
   >    the char[]   
      
   This is now called "Pascal strings", but PL/I had it first.   
      
   > - ideally, an option for the length to be dynamic, reallocating   
   >    the memory as needed. Would require the base representation   
   >    to be a pointer to the struct. Would be a lot of "under the   
   >    hood" stuff, and probably inefficient.   
   >   
   > ** and now a digression **   
   >   
   > The VAX architecture with its descriptors and universal calling   
   > sequences was a great foundation, but K&R C did not fit, because   
   > a byte-addressed memory was assumed, and you could not put the   
   > descriptors in the middle of a struct and still have the code be   
   > portable. So for anything with networking, which relied on being   
   > able to import the Berkeley networking code, all the descriptor   
   > stuff was of no use. For a lot of other code, it was amazingly   
   > good. The unified calling structure and the way an exception   
   > could be unwound up multiple levels of stack and simply be   
   > converted to an error return code at the top level of a layered   
   > library was pretty miraculous. And the instruction set was   
   > very intuitive. I wrote a lot of kernel code in Macro-32,   
   > and it was almost as fast as writing C.   
      
   I agree that VAX programming was the nuts. The only problem I had with   
   Macro-32 was that there were so many ways of doing something that I, as   
   a VAX newbie, spent a lot of time overthinking: "do I want to use a   
   three-address or a two-address instruction here?"   
      
   >   
   > The people in comp.arch look down of how inefficient the VAX   
   > was, and how the microcode tricks used to make fast CPUs with   
   > pipelining and out-of-order execution would not work for a VAX.   
   > I think that is just an example of how the arch of history often   
   > looks inevitable in hindsight.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)