From coff at tuhs.org Tue Jan 6 04:16:44 2026 From: coff at tuhs.org (Clem Cole via COFF) Date: Mon, 5 Jan 2026 13:16:44 -0500 Subject: [COFF] C vs Pascal thoughts - was [TUHS] Buffer overflow found/fixed in v4 tape ; ) Message-ID: Moving to COFF, bcc TUHS On Mon, Jan 5, 2026 at 12:47 PM Bakul Shah wrote: > Actually Pascal got a lot of things right. Coming from being intimately > familiar with Pascal and its orig. compiler, I disliked these things in C: > 1. poor array support, no multi-dim arrays > 2. C's union type vs Pascal's variant records > 3. no subrange type > 4. C's poor type system > 5. C's enum type which are essentiall integers vs Pascal's strict > enumeration type > 6. No nested functions. > > [Of course, there were many things to like in C as well.] > > Granted, it was not as clean and orthogonal as Algol68 (whose popularity > suffered from surface issues such as use of vW grammar od choice of > keywords > etc.). > > Also note that pretty much all non-C compilers pre-1988 generate code to > do bounds check -- at least as an option but more often the option was to > turn *off* bounds check! > > Now that we are aware of the danger of no bounds check, we seem to have > gone > to other extreme of using complicated languages like Rust.... I, too, don't "hate" Pascal and don't argue with the strengths it demonstrated. But I have one primary issue: *"Which Pascal do you mean?" *When I worked at Tektronix, Ward Cunningham and I counted 14 different "Tek Pascals" in use at the time. The paper "*Why Pascal is not my Favorite Programming Language*" [ https://web.archive.org/web/20060821183401/http://cm.bell-labs.com/cm/cs/cstr/100.ps.gz ] offers up the fundamental issues. I suggest looking at Ward's Wiki [ https://wiki.c2.com/?WhyPascalIsNotMyFavoriteProgrammingLanguage ] as there are some interesting comments. I think this observation is also important: > "Interestingly, many of Kernighan's objections to Pascal are things that > Knuth also found it necessary to address in his LiterateProgramming > tool "Web", which he used in > the development of TexTheProgram and > Metafont. It is fair to say that the Web system is only half about > LiterateProgramming ; the other > half is just workarounds for the shortcomings of the Pascal dialects of its > day. Most notably, Web provides a mechanism to allow the use of > variable-length strings in things like error messages." From coff at tuhs.org Tue Jan 6 06:36:58 2026 From: coff at tuhs.org (Arnold Robbins via COFF) Date: Mon, 05 Jan 2026 13:36:58 -0700 Subject: [COFF] [TUHS] Re: C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; ) In-Reply-To: References: Message-ID: <202601052036.605KawDA036756@freefriends.org> Clem Cole via TUHS wrote: > The paper "*Why Pascal is not my Favorite Programming Language*" [ > https://web.archive.org/web/20060821183401/http://cm.bell-labs.com/cm/cs/cstr/100.ps.gz > ] offers up the fundamental issues. As a side note, a better source is https://github.com/arnoldrobbins/cstr100, which has the troff-able source of the paper, courtesy of BWK. Arnold From coff at tuhs.org Tue Jan 6 06:39:22 2026 From: coff at tuhs.org (Dan Cross via COFF) Date: Mon, 5 Jan 2026 15:39:22 -0500 Subject: [COFF] [TUHS] Re: Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> Message-ID: [Note: TUHS to Bcc: and Cc: to COFF. This has nothing to do with Unix] On Mon, Jan 5, 2026 at 2:16 PM Steffen Nurpmeso via TUHS wrote: > [snip] > ..and fact is that any language i know supports bound-checked > array accesses. You only have to code it. And have the > discipline to use that interface, and that interface alone. > This argument extends to more things. Note: you took a note about what Rust does with bounds checking, and turned it into a rant about how you don't see value in memory safety. My experience is that people tend to react to languages things like Rust in one of three ways: 1) they are unabashed fan boys who suggest that anyone not programming in Rust is an idiot, 2) they acknowledge the strengths and potential benefits and can appreciate the positives of programming at a higher level of abstraction, while still pointing out flaws and being cautious about potential pitfalls (tooling, complexity, training, whatever; you name it), or 3) they assert that there's nothing useful here and anyone who's programming in Rust is an idiot desperately looking for tools to cover up their incompetence, and that the real solution is to just be a Better Programmer. Of course, Rust is just an example here; these broad categories of reactions are true of any number of technologies. Of the three, I've found that those falling into the first camp basically never write software but spend an awful lot of time writing blogs or commenting on hacker news. Those in the third category are similar, though they've likely _stopped_ writing lots of code. Those in the second category, who can appreciate nuance and weigh tradeoffs objectively, tend to be the best engineers. My own take here is your argument defeats itself in the above paragraph: 60 years of professional programming history have shown that those "only have to code it" and "having the discipline" things don't hold up at scale. Sure, we can all belly up to the bar and complain about how the kids these days just don't have the skill, intelligence, or intestinal fortitude to write competent C code, but professionals understand that tools evolve and defense-in-depth and automation are good when it comes to writing reliable software. If you think it's just a matter of discipline, well...good luck with that. History and available evidence disagree. > In early September 2024 there was a very long thread on some > FreeBSD list where a long time contributor and kernel hacker > jumped into the at that time "hot" (there was that Linux > filesystem discussion thing where a Rust promoter stepped down > not back after claiming that ~"blocking Rust" is "non-technical > nonsense" (Google says for "linux rust non-techincal nonsense"). > And he said > > |> In fact, of all the C bug fixes that I've been involved with (as > |> either author or reviewer) since May, about three quarters could've > |> been avoided just by using a better language. > |... > |> To summarize, here's the list of this week's security advisories, and > |> also some other recent C bug fixes of my own involvement > > That really interested me, and i looked over them [1], likely not > longer than a minute code-looking for each one (claiming t"he ones > from OpenSSL and ctld are more complex" instead of looking more > deeply), and i ended up saying > > Examples. I find the absolute opposite after checking four. I don't see how this can be claimed to be the "opposite." It may be that you aren't convinced that Rust has any advantages over C for the examples given that you looked at, but that is very different than claiming that Rust makes the code _worse_ and unsafe (which is what the opposite claim implies). > Later in the thread one developer of a patch i did not look > further into because of complexity stated his was ~"not a C error" > either. So that is that. > > And then, how could any language help when, as i say in [1], > "a byte buffer of reality matches a structure of a language > abstraction". More than C? > And things often seen in C, beyond that struct{x;y;char flex[];}, > where a larger buffer is allocated to store some structure at > the bottom and a buffer thereafter, in one hot memory chunk. > You can create an interface that accesses memory within "flex" > safely, even then. > And then you can use a string object that knows its length. > And all that -- you all know that, better than i do. > > In the non-mellow sphere of programmers lots of sledgehammerheads > bang into this "memory safe" notch, as if they were the "king of > the bongo .. bong!". > > Whereas i think it is beneficial to create a wider context so that > at least in certain forums different realities can be heard. > Not that it all ends up with AI rewriting any C or C++ code in > Rust, without any little human programmer getting paid for > anything of that rewrite, which does not fix just one logic error. > > [1] https://marc.info/?l=freebsd-hackers&m=172557660704363&w=2 > > Array bound checking, i mean, come on. Cheech and Chong are > beaners without that. That's a racial slur. Not cool. - Dan C. From coff at tuhs.org Tue Jan 6 07:00:39 2026 From: coff at tuhs.org (Larry McVoy via COFF) Date: Mon, 5 Jan 2026 13:00:39 -0800 Subject: [COFF] [TUHS] Re: Buffer overflow found/fixed in v4 tape ;) In-Reply-To: References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> Message-ID: <20260105210039.GU4609@mcvoy.com> On Mon, Jan 05, 2026 at 03:39:22PM -0500, Dan Cross via COFF wrote: > If you think it's just a matter of discipline, well...good luck with > that. History and available evidence disagree. (Dan commenting on people saying that C can work). I tend to be in the camp that you can make C work, but it takes a lot of discipline. My kid is in the CS PhD program at USC and he asked me about C. My answer was: "C is like a sports car on a twisty mountain road where the edge of the road is a cliff. If you take your eyes off the road, it's pretty much instant death. So it doesn't work for the people who want to text and drive. On the other hand, if you are an expert driver, are 100% focussed on the drive, it's fun. C is like that. It doesn't work well for a lot of people, but it can be fun and work very well for a small subset of programmers". My existence proof is the company I ran for 18 years, we built a pretty complex product and had very little in the way of overruns. We did have a test case that threw fuzz and the command line args and stdin that caught a lot in the early days, not so much as we became more disciplined. If I were starting over, I'd probably still do C if I had a similar set of programmers, it's really not a problem if you do things correctly. But I'm sympathetic to the people that say they need the guard rails. As an old school programmer, I'm baffled that you need them, I find it sad. As a realistic person, bring on the guard rails. And I'm happy I'm retired and don't have to fight these fights. From coff at tuhs.org Tue Jan 6 08:23:38 2026 From: coff at tuhs.org (Bakul Shah via COFF) Date: Mon, 5 Jan 2026 14:23:38 -0800 Subject: [COFF] [TUHS] C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; ) In-Reply-To: References: Message-ID: > On Jan 5, 2026, at 10:16 AM, Clem Cole via TUHS wrote: > > Moving to COFF, bcc TUHS > > On Mon, Jan 5, 2026 at 12:47 PM Bakul Shah wrote: > >> Actually Pascal got a lot of things right. Coming from being intimately >> familiar with Pascal and its orig. compiler, I disliked these things in C: >> 1. poor array support, no multi-dim arrays >> 2. C's union type vs Pascal's variant records >> 3. no subrange type >> 4. C's poor type system >> 5. C's enum type which are essentiall integers vs Pascal's strict >> enumeration type >> 6. No nested functions. >> >> [Of course, there were many things to like in C as well.] >> >> Granted, it was not as clean and orthogonal as Algol68 (whose popularity >> suffered from surface issues such as use of vW grammar od choice of >> keywords >> etc.). >> >> Also note that pretty much all non-C compilers pre-1988 generate code to >> do bounds check -- at least as an option but more often the option was to >> turn *off* bounds check! >> >> Now that we are aware of the danger of no bounds check, we seem to have >> gone >> to other extreme of using complicated languages like Rust.... > > > I, too, don't "hate" Pascal and don't argue with the strengths it > demonstrated. But I have one primary issue: *"Which Pascal do you > mean?" *When > I worked at Tektronix, Ward Cunningham and I counted 14 different "Tek > Pascals" in use at the time. The paper "*Why Pascal is not my Favorite I used The "Pascal User Manual and Report" as *the* Pascal, though granted it didn't pin down nitty gritty details. May be why there were so many variants (also due to small memory sizes of microcomputers of the era). > Programming Language*" [ > https://web.archive.org/web/20060821183401/http://cm.bell-labs.com/cm/cs/cstr/100.ps.gz > ] offers up the fundamental issues. I suggest looking at Ward's Wiki [ > https://wiki.c2.com/?WhyPascalIsNotMyFavoriteProgrammingLanguage ] as there > are some interesting comments. I reread bwk's paper after a long time (thanks Arnold for the link to troffable paper). Just a quick impression: He says (talking about range types) "although of course run-time checking does exact a penalty." Of course it does in the general case, but this criticism seems funny now in light of buffer overflow issues! 2.1 (array size part of its type) is a definite issue. This was more or less fixed in the 1985 Pascal std with "conformant arrays" (but not well enough IMHO). bwk also talks about strings. Perhaps a "string" type would have been better. 2.2 static variables -- I tend to believe using static vars is usually a mistake. Initialization -- saves some typing but that is about it. 2.3 related components have to be kept separate. 2.4 separate compilation -- yes, this was a problem. Ironically C had separate compilation but its weak type system made it error prone (and not fixed for years). 2.5 misc. I saw these more as a lack of convenience than intrinsic to Pascal. These were probably added by some variants later. bwk says "But the calling program has no way to declare that a variable is to be modified". Perhaps he means "no way to *note* that a variable is to be modified". C indicates this by &var syntax but this adds to inconvenience in the called function (have to explicitly deref it or use -> for struct fields). 2.6 no cast. I think casts are actually a misfeature of C. I once had to fix a program that was "lint free" (back in 1980s) but kept crashing. Turned out the client's programmers used casts liberally to shut up the linter! 3 control flow - these seem nitpicky. 4 environment & io. IO was certainly a weak point of Pascal. Both language designs were the result/victims of their intended audience. Perhaps Pascal as a teaching language didn't have enough real life use (early its life) to debug IO design, add convenience features etc. The way C grew, working code to solve real problems was more important than any theoretical soundness. > > I think this observation is also important: > >> "Interestingly, many of Kernighan's objections to Pascal are things that >> Knuth also found it necessary to address in his LiterateProgramming >> tool "Web", which he used in >> the development of TexTheProgram and >> Metafont. It is fair to say that the Web system is only half about >> LiterateProgramming ; the other >> half is just workarounds for the shortcomings of the Pascal dialects of its >> day. Most notably, Web provides a mechanism to allow the use of >> variable-length strings in things like error messages." Pascal's shortcomings were solvable (but weren't) while we are still paying for C's shortcomings. From coff at tuhs.org Tue Jan 6 08:28:48 2026 From: coff at tuhs.org (segaloco via COFF) Date: Mon, 05 Jan 2026 22:28:48 +0000 Subject: [COFF] [TUHS] Re: Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <20260105210039.GU4609@mcvoy.com> References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> <20260105210039.GU4609@mcvoy.com> Message-ID: <6XR694h6xebLdIS8Lcoyd2_7llJn6ejAg2WYQBj-2UAxItrSnAjO3-GpevhscyZ1XUDcIf8vVkUhywc9BIwar97Fu3B5sERUeLWuyXfSZPo=@protonmail.com> On Monday, January 5th, 2026 at 13:00, Larry McVoy via COFF wrote: > But I'm sympathetic to the people that say they need the guard rails. > As an old school programmer, I'm baffled that you need them, I find it > sad. As a realistic person, bring on the guard rails. And I'm happy Long musings on guardrails and accessibility incoming... It's 2026 and most of the code that passes through my fingers outside of my day job is still assembly (mostly 6502). Watching trend after trend go by while I plink around with bare-metal microcontrollers is amusing. At the end of the day, I recognize that *what is being done* is noble and good, I can hardly find fault in anyone trying in earnest to make programming safer (and thereby more accessible). The problem I have is *how it is being done*. Some languages and environments have given up on the inquisitive, risk-taking hacker and pander instead to the rapid-fire vibe coder. Is this a problem? Not necessarily IMO. Just like languages have proliferated for different use-cases from a technical perspective (systems vs. industrial control vs. business vs. science, highly parallel vs. hard-real-time, so on and so forth), I feel they proliferate for different skill levels and goals. Sure if you're an expert fiber artist trying to sew a beautiful dress, childrens safety scissors seem like a joke. But if you're a kid who has until then only had the option of ripping your paper by hand, some crappy little Fiskars are a godsend. To get back to the how, I worry about folks getting pigeonholed, about an easier language being treated as an end-all-be-all and a permanent investment. You learn to ride a fixed gear with training wheels, then upgrade to no training wheels, then to a multi-speed (then to a motorcycle). In my own day job, I don't really see any kind of progression like this encouraged. Part of it is logistics, sure, can't have people switching languages all the time. But still, the languages we use are "sold" on their ease of use, but I have had multiple occasions of cursing the fact that cool, I know this stuff, but I've myself graduated to languages that require much more finesse and thought but reward me richly, and I cannot enjoy the rich reward of having found a better way of doing something because it can't be expressed adequately in the "easy" language. It doesn't matter to my professional career right now because the least common denominator is the programmers on the team that would be lost without C# and .NET (not a dig, but a sympathetic understanding of being where I was in my own past). What this speaks to in my mind is a benefit for increasing the interoperability of different languages and environments. Sure plenty of libraries and systems have binding methods to make your C function, say, available to your FORTRAN programs, but these mechanisms tend to be hit or miss depending on the implementation. Just as we are entering an age of mote automated translation, there are now devices that'll do the sci-fi-esque live translation stuff in bot directions, I have to wonder, is interoperability between programming systems going to get more or less attention as time goes on? I think there are some strong cases to be made for "multi-lingual" programming, not least of which is more "upwards mobility" inspiring programmers to get better at their craft holistically rather than becoming yoked under the very languages that gave them success in the first place. All in all, I simply wish there was more of a trend of "upgrading languages" more regularly, taking on more precise or more expressive vehicles as one goes, rather than having to invest in a specific language and then forever be beholden to or influenced by its specific "accent". - Matt G. From coff at tuhs.org Tue Jan 6 08:40:31 2026 From: coff at tuhs.org (Douglas McIlroy via COFF) Date: Mon, 5 Jan 2026 17:40:31 -0500 Subject: [COFF] [TUHS] Buffer overflow found/fixed in v4 tape Message-ID: This item reminded me of a couple of non-Unix stories about important Unix people > The weekly pay calculation often yielded amounts in fractions > of pennies. These were either rounded up or down to the nearest cent. The > fractional pennies were tracked in an account called the breakage account. > This programmer had created a fake employee in the company's computer > records and had a check printed for that "person" An early indication of Bob Morris's future as NSA's chief scientist: Having left his fingerprints all over Unix security measures, Bob took on an ever-widening role as Bell Labs' leading computer-security consultant. When the payroll department asked him to evaluate their operation, his first question was, "How do you handle the annual pennies adjustment?" The astute insight of this question instantly bolstered the hosts' respect for Bob. He had jumped straight to a matter they were aware of, but had never audited. Although it appeared on everyone's year-end pay stub, who would have bothered to confirm it? Well, maybe Joe Ossanna would have checked. When he took out a mortgage, he discovered that the installments were about 1% higher than he had calculated. He complained to the bank, which explained that NJ law said interest may be computed either for a calendar year or for a nominal 360-day year. Naturally the bank chose to pay interest by the calendar year and to charge interest by the nominal year--a more lucrative hustle than penny rounding! Doug From coff at tuhs.org Tue Jan 6 08:57:10 2026 From: coff at tuhs.org (Larry McVoy via COFF) Date: Mon, 5 Jan 2026 14:57:10 -0800 Subject: [COFF] [TUHS] Re: Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <6XR694h6xebLdIS8Lcoyd2_7llJn6ejAg2WYQBj-2UAxItrSnAjO3-GpevhscyZ1XUDcIf8vVkUhywc9BIwar97Fu3B5sERUeLWuyXfSZPo=@protonmail.com> References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> <20260105210039.GU4609@mcvoy.com> <6XR694h6xebLdIS8Lcoyd2_7llJn6ejAg2WYQBj-2UAxItrSnAjO3-GpevhscyZ1XUDcIf8vVkUhywc9BIwar97Fu3B5sERUeLWuyXfSZPo=@protonmail.com> Message-ID: <20260105225710.GV4609@mcvoy.com> On Mon, Jan 05, 2026 at 10:28:48PM +0000, segaloco via COFF wrote: > All in all, I simply wish there was more of a trend of "upgrading > languages" more regularly, taking on more precise or more expressive > vehicles as one goes, rather than having to invest in a specific language > and then forever be beholden to or influenced by its specific "accent". Amen, brother. A large part of the complaints with C would evaporate if there was a C with a string type. Where the allocation, reallocation, truncation, etc, all happened under the type. Lots and lots of the buffer overflows are on buffers that are for strings. Add a string type and they go away. I find it distasteful that people think they need to invent a new syntax to solve their $PROBLEM. It doesn't respect the investment people have made in learning C syntax to force rust syntax or Go syntax on them. I made an attempt to make an advanced C, it never really went anywhere, I'm probably the only user. But it shows you how far you can push C syntax. It's pretty far. https://www.little-lang.org/ -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From coff at tuhs.org Tue Jan 6 15:08:39 2026 From: coff at tuhs.org (Bakul Shah via COFF) Date: Mon, 5 Jan 2026 21:08:39 -0800 Subject: [COFF] [TUHS] Re: Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <6XR694h6xebLdIS8Lcoyd2_7llJn6ejAg2WYQBj-2UAxItrSnAjO3-GpevhscyZ1XUDcIf8vVkUhywc9BIwar97Fu3B5sERUeLWuyXfSZPo=@protonmail.com> References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> <20260105210039.GU4609@mcvoy.com> <6XR694h6xebLdIS8Lcoyd2_7llJn6ejAg2WYQBj-2UAxItrSnAjO3-GpevhscyZ1XUDcIf8vVkUhywc9BIwar97Fu3B5sERUeLWuyXfSZPo=@protonmail.com> Message-ID: > On Jan 5, 2026, at 2:28 PM, segaloco via COFF wrote: > > I think there are some strong cases to be made for "multi-lingual" programming, not least of which is more "upwards mobility" inspiring programmers to get better at their craft holistically rather than becoming yoked under the very languages that gave them success in the first place. All in all, I simply wish there was more of a trend of "upgrading languages" more regularly, taking on more precise or more expressive vehicles as one goes, rather than having to invest in a specific language and then forever be beholden to or influenced by its specific "accent". This might be instructive re upgrading languages: https://www.youtube.com/watch?v=NTrAISNdf70 Thompson tells how he developed the Go language at Google. youtube.com From coff at tuhs.org Tue Jan 6 15:08:39 2026 From: coff at tuhs.org (Bakul Shah via COFF) Date: Mon, 5 Jan 2026 21:08:39 -0800 Subject: [COFF] [TUHS] Re: Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <6XR694h6xebLdIS8Lcoyd2_7llJn6ejAg2WYQBj-2UAxItrSnAjO3-GpevhscyZ1XUDcIf8vVkUhywc9BIwar97Fu3B5sERUeLWuyXfSZPo=@protonmail.com> References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> <20260105210039.GU4609@mcvoy.com> <6XR694h6xebLdIS8Lcoyd2_7llJn6ejAg2WYQBj-2UAxItrSnAjO3-GpevhscyZ1XUDcIf8vVkUhywc9BIwar97Fu3B5sERUeLWuyXfSZPo=@protonmail.com> Message-ID: > On Jan 5, 2026, at 2:28 PM, segaloco via COFF wrote: > > I think there are some strong cases to be made for "multi-lingual" programming, not least of which is more "upwards mobility" inspiring programmers to get better at their craft holistically rather than becoming yoked under the very languages that gave them success in the first place. All in all, I simply wish there was more of a trend of "upgrading languages" more regularly, taking on more precise or more expressive vehicles as one goes, rather than having to invest in a specific language and then forever be beholden to or influenced by its specific "accent". This might be instructive re upgrading languages: https://www.youtube.com/watch?v=NTrAISNdf70 Thompson tells how he developed the Go language at Google. youtube.com From coff at tuhs.org Wed Jan 7 02:37:58 2026 From: coff at tuhs.org (Paul Winalski via COFF) Date: Tue, 6 Jan 2026 11:37:58 -0500 Subject: [COFF] [TUHS] C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; ) In-Reply-To: References: Message-ID: On Mon, Jan 5, 2026 at 5:31 PM Bakul Shah via COFF wrote: > > 2.2 static variables -- I tend to believe using static vars is usually > a mistake. Initialization -- saves some typing but that is about it. > > Static variables are useful where a subroutine must retain context betwen invocations. For example, the seed for a pseudo-random number generator. -Paul W. From coff at tuhs.org Wed Jan 7 02:53:51 2026 From: coff at tuhs.org (Dan Cross via COFF) Date: Tue, 6 Jan 2026 11:53:51 -0500 Subject: [COFF] [TUHS] C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; ) In-Reply-To: References: Message-ID: On Tue, Jan 6, 2026 at 11:38 AM Paul Winalski via COFF wrote: > On Mon, Jan 5, 2026 at 5:31 PM Bakul Shah via COFF wrote: > > 2.2 static variables -- I tend to believe using static vars is usually > > a mistake. Initialization -- saves some typing but that is about it. > > Static variables are useful where a subroutine must retain context between > invocations. For example, the seed for a pseudo-random number generator. Surely one could do that with a global, as well. Common Lisp had an interesting mechanism that one could pervert^Wuse for such things, without using a dynamic variable: define a function inside of a `let`: ``` * (let ((a 0)) (defun incr () (setf a (+ a 1)) a)) INCR * (incr) 1 * (incr) 2 * (incr) 3 * ``` I briefly wondered if Pascal's support for lexically nested functions might be leveraged for something like this: presumably the "inner" function could treat the outer function's variables like statics, but given that the inner functions are not themselves directly accessible, I don't think so; they're not closures. - Dan C. From coff at tuhs.org Wed Jan 7 02:59:30 2026 From: coff at tuhs.org (Paul Winalski via COFF) Date: Tue, 6 Jan 2026 11:59:30 -0500 Subject: [COFF] [TUHS] Re: Buffer overflow found/fixed in v4 tape ;) In-Reply-To: <20260105210039.GU4609@mcvoy.com> References: <20260105190558.ne1rlUzN@steffen%sdaoden.eu> <20260105210039.GU4609@mcvoy.com> Message-ID: On Mon, Jan 5, 2026 at 4:00 PM Larry McVoy via COFF wrote: > > I tend to be in the camp that you can make C work, but it takes a lot of > discipline. My kid is in the CS PhD program at USC and he asked me about > C. My answer was: "C is like a sports car on a twisty mountain road where > the edge of the road is a cliff. If you take your eyes off the road, it's > pretty much instant death. So it doesn't work for the people who want to > text and drive. On the other hand, if you are an expert driver, are 100% > focussed on the drive, it's fun. C is like that. It doesn't work well > for a lot of people, but it can be fun and work very well for a small > subset of programmers". > BLISS is even worse. It's an unguarded band saw. C at least has data typing, even if it is somewhat fast and loose. BLISS has no data types (or more correctly, exactly one data type--the BLISS value). That, and the explicit fetch operator, mean one must program very carefully. -Paul W. From coff at tuhs.org Wed Jan 7 03:08:29 2026 From: coff at tuhs.org (segaloco via COFF) Date: Tue, 06 Jan 2026 17:08:29 +0000 Subject: [COFF] [TUHS] C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; ) In-Reply-To: References: Message-ID: On Tuesday, January 6th, 2026 at 08:54, Dan Cross via COFF wrote: > On Tue, Jan 6, 2026 at 11:38 AM Paul Winalski via COFF coff at tuhs.org wrote: > > > On Mon, Jan 5, 2026 at 5:31 PM Bakul Shah via COFF coff at tuhs.org wrote: > > > > > 2.2 static variables -- I tend to believe using static vars is usually > > > a mistake. Initialization -- saves some typing but that is about it. > > > > Static variables are useful where a subroutine must retain context between > > invocations. For example, the seed for a pseudo-random number generator. > > > Surely one could do that with a global, as well. > > - Dan C. The distinction for me becomes a matter of safety. A new developer on the product poking around and changing random things is a lot more likely to accidentally find and change a global from some random place than to find and change a block-scoped static variable. Static affords no runtime checking of access, but it does ensure your compiler isn't liable to be pimping out that pointer to other areas itself. Granted, you start passing around a pointer to that underlying static variable and all bets are off. - Matt G. From coff at tuhs.org Wed Jan 7 03:41:47 2026 From: coff at tuhs.org (Bakul Shah via COFF) Date: Tue, 6 Jan 2026 09:41:47 -0800 Subject: [COFF] [TUHS] C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; ) In-Reply-To: References: Message-ID: On Jan 6, 2026, at 8:37 AM, Paul Winalski wrote: > > On Mon, Jan 5, 2026 at 5:31 PM Bakul Shah via COFF wrote: > > 2.2 static variables -- I tend to believe using static vars is usually > a mistake. Initialization -- saves some typing but that is about it. > > Static variables are useful where a subroutine must retain context betwen invocations. For example, the seed for a pseudo-random number generator. > > -Paul W. Static variables are essentially the same as global variables except with local scope. This is a problem for concurrency. A better solution is to use nested procedures such as (using Scheme syntax) (define (make-random seed) ; return a function returning a random number (lambda () (let ((return-value (some-randomizing-function seed))) (set! seed (new-seed seed)) return-value)))) (define my-random (make-random 314159265)) (my-random) (my-random) etc. Now you can give each thread its own random function. This is also why we have "reentrant" versions of common functions. For example readdir_r(3) that will work predictably if two separate threads try to read dir entries from the same opened dir. Also note that newer languages "frown" upon global variables. In V for example you have to pass a command line arg to allow any global variables! Global constants are fine. Personally I would define a "shared" attribute and allow shared globals -- the idea being any access to shared variables is protected via mutexes -- Idea I first saw in Brinch Hansen's red OS book (operating system principles). Here's the orig paper: https://dl.acm.org/doi/epdf/10.1145/361454.361473 From coff at tuhs.org Wed Jan 7 04:28:37 2026 From: coff at tuhs.org (segaloco via COFF) Date: Tue, 06 Jan 2026 18:28:37 +0000 Subject: [COFF] [TUHS] C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; ) In-Reply-To: References: Message-ID: <0TPMgMPwsa6O07gZPqy-GB_wgfFdBk0h7ia1YZAjPY1LKI4tck2ogbpZyknWEAnk1_n3-9b5xaDZr_rX31LSWo25e6DXgJp9wveJPkzFc34=@protonmail.com> On Tuesday, January 6th, 2026 at 09:42, Bakul Shah via COFF wrote: > > Personally I would define a "shared" attribute and allow shared globals -- the idea being any access to shared variables is protected via mutexes -- > Like all things, this sounds great as long as I can turn it off when I know, by definition, collisions shouldn't happen. Otherwise I'm potentially avoiding a race condition (good!) in code that by definition should not be capable of a race condition (bad!), side-stepping the root cause entirely. I should fix that, not my compiler/language. Those are the kinds of things that do keep me up at night with all the "hand-holding" in modern programming systems. Sure, it'll keep me from invalid access without having to pay it much mind, but I *want* to pay my invalid accesses some mind to tighten up my algorithm, not just hope the language fixes it in post. - Matt G. From coff at tuhs.org Wed Jan 7 05:23:06 2026 From: coff at tuhs.org (Bakul Shah via COFF) Date: Tue, 6 Jan 2026 11:23:06 -0800 Subject: [COFF] [TUHS] C vs Pascal thoughts - was Buffer overflow found/fixed in v4 tape ; ) In-Reply-To: <0TPMgMPwsa6O07gZPqy-GB_wgfFdBk0h7ia1YZAjPY1LKI4tck2ogbpZyknWEAnk1_n3-9b5xaDZr_rX31LSWo25e6DXgJp9wveJPkzFc34=@protonmail.com> References: <0TPMgMPwsa6O07gZPqy-GB_wgfFdBk0h7ia1YZAjPY1LKI4tck2ogbpZyknWEAnk1_n3-9b5xaDZr_rX31LSWo25e6DXgJp9wveJPkzFc34=@protonmail.com> Message-ID: <4E6173D8-6EA4-4BC3-8519-FCDFB2FAEFF1@iitbombay.org> > On Jan 6, 2026, at 10:28 AM, segaloco via COFF wrote: > > On Tuesday, January 6th, 2026 at 09:42, Bakul Shah via COFF wrote: > >> >> Personally I would define a "shared" attribute and allow shared globals -- the idea being any access to shared variables is protected via mutexes -- >> > > Like all things, this sounds great as long as I can turn it off when I > know, by definition, collisions shouldn't happen. Otherwise I'm > potentially avoiding a race condition (good!) in code that by definition > should not be capable of a race condition (bad!), side-stepping the root > cause entirely. I should fix that, not my compiler/language. Critical sections *are* a solution to avoiding race conditions! Better that the compiler always puts in necessary code to implement critical sections. *You* may be smart enough to find and fix race conditions but in general race conditions are extremely hart to catch. [A colleague and I once had to spent 14 days of 16 hour workdays because of a race condition in V7 Unix that somehow escaped the original unix wizards] And when code changes, every time you have to recheck that "collisions shouldn't happen" remains true. > > Those are the kinds of things that do keep me up at night with all the > "hand-holding" in modern programming systems. Sure, it'll keep me from > invalid access without having to pay it much mind, but I *want* to pay > my invalid accesses some mind to tighten up my algorithm, not just hope > the language fixes it in post. > > - Matt G. It depends on how you look at languages that provide more expressive power and proper abstractions. If multiple threads are sharing a variable, I want to express that and have the compiler relieve me of the grunge work of checking for race conditions every time (at least for *that* variable). PLs are for communicating algorithms not just to compilers but also humans. Ideally one wants correct, clear, concise and efficient code but very hard to achieve all four (at least across the broad spectrum of use cases).