XPost: comp.os.linux.misc, alt.folklore.computers   
   From: lars@beagle-ears.com   
      
   [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[]   
   - 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.   
      
   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.   
   --   
   Lars Poulsen - an old geek in Santa Barbara, California   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)