I thought their main arguments were to use memory-safe languages. Are you saying the C language can be as safe s go, rust, etc., by language design? (I don't think you are, but the sentence I quoted kinda implies that, at least to me.)

It doesn't have to be that way, C could be evolved, I built a very C like language (to the point that one of my engineers, who hated the new language on principle, fixed a bug in some diffs that flew by, he thought he was fixing a bug in C). No pointers, reference counted garbage collection, pass by value or reference, switch values could be anything, values, variables, regular expressions, etc. If I had infinite energy and money, I'd fund a gcc dialect of that C. Alas, I don't. But C is very fixable. On Mon, Sep 30, 2024 at 09:56:47AM +1000, Rob Pike wrote: -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat

C# addresses some of the things being discussed here. I've used it, I don't care for it all that much, I prefer straight, not-at-all modern C, but I think there are probably a few dialects over the years (Objective C ?) that have addressed some of these desires for a "better C, but not C++". Do others here have comments on these inspired by C, kind of C-like, but with a few other computer science components, thrown into the language machine ? On 09/29/2024 05:36 PM, Larry McVoy wrote:

Data point. I hope this is not too far out of TUHS scope, but ... you asked. In 2010, we at sandia journeyed to Usenix to take Russ's course on Go. At that time, we had created megatux, all written in C, all based on earlier HPC work at LANL, that allowed us to run 80,000 or so Windows VMs on a 400 node cluster, and from there run real malware to study it (and, in one case, fix a bug :-). We got done Russ's course, and on the way home, I said "we're moving it all to Go." Nobody disagreed. We never once regretted that decision. On Sun, Sep 29, 2024 at 6:47 PM Luther Johnson <luther.johnson(a)makerlisp.com> wrote:

Rob Pike wrote in &lt;CAKzdPgwJ7-_BWztOQKiB6h5a+OGwXtefsD47Fq+GDwGGF7N4UA(a)mail.gmail.com&gt;: |On Mon, Sep 30, 2024 at 2:56 AM Douglas McIlroy < |douglas.mcilroy(a)dartmouth.edu&gt; wrote: |>>>> malloc(0) isn't undefined behaviour but implementation defined. |>>> |>>> In modern C there is no difference between those two concepts. |> |>> Can you explain more about your view |> |> There certainly is a difference, but in this case the practical |> implications are the same: avoid malloc(0). malloc(0) lies at the \ |> high end |> of a range of severity of concerns about implementation-definedness. \ |> At the |> low end are things like the size of ints, which only affects applications |> that may confront very large numbers. In the middle is the default |> signedness of chars, which generally may be mitigated by explicit type |> declarations. |> |> For the size of ints, C offers guardrails like INT_MAX. There is no test |> to discern what an error return from malloc(0) means. |> |> Is there any other C construct that implementation-definedness renders |> useless? |Gradually the writers of optimizing compilers have leaned so hard on the |implementation-defined and undefined behaviors that, while far from |useless, C and C++ have become non-portable and dangerously insecure, as |well as often very surprising to the point that the US government arguing |against using them. Never attribute to malice what can adequately be explained by incompetence. is the signature of Poul-Henning Kamp (whose email regarding that cstr list (i did not yet have TM-74-1273-1 aka the C Reference Manual as of 1974-01-15, thank you!) was forwarded by Warren). Only propaganda left everywhere, including here, namely for Rust. But your statement in particular reminds me of "Who's afraid of a big bad optimizing compiler?" of LWN.net, from July 15, 2019. It may be fun to read by some. (Offline, searching surely works.) It ends with Acknowledgments We owe thanks to a surprisingly large number of compiler writers and members of the C and C++ standards committees who introduced us to some of the things a big bad optimizing compiler can do,[.] But i think those eh people there (that US government) surely have been hammered with "memory-safe language" a thousand times, and noone ever told them that even the eldest C can be used in a safe way; on freebsd-hackers (PHK is an early FreeBSD committer) there was one of their bikeshed threads around September 5th, after several CVEs where fixed, and another long time major contributor started a thread saying things like |>|The real takeaway here is that C is no longer sufficient for writing |>|high quality code in the 2020s. Everyone needs to adapt their tools. which (also) i (not FreeBSD, only by heart, maybe) spoke against. He was hailing Option<Box<Vec<u8>>> or Vec::with_capacity(262144) as solutions to the CVEs. (Which, as far as i looked, had nothing really to do with C as such; one "guilty" programmer said, as far as i understood that, the same for "his CVE".) Vectors and string "objects" with (optionally) checked index access and such are uncomfortable, but easy to do, also with C, and right from the start (i said). (P.S.: i miss bit enumerations in C and C++, as compilers get stricter and stricter (you cannot even enum1|enum2 without warnings no more, in i think C23; without cast, of course), but bit flags "can" only come in via preprocessor constants, and are completely unchecked. And enum1|enum2 *i* often have, if some subtype adds flags on top of a basic type, isn't that natural, no support on that front. And cast-less "super class casts". I had not downloaded cstr#108-the_c++_programming_language yet.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Rich Salz wrote in &lt;CAFH29tp4fZR7ct57F-BmyqoJwwRfHkSbiVPS1mj89e-_gzhsHQ(a)mail.gmail.com&gt;: |On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso &lt;steffen(a)sdaoden.eu&gt; wrote |> noone ever told them that even the eldest C can be used in a safe |> way; | |Perhaps we have different meanings of the word safe. | | void foo(char *p) { /* interesting stuff here */ ; free(p); } | void bar() { char *p = malloc(20); | foo(p); | printf("foo is %s\n", p); | foo(p); |} |Why should I have to think about this code when the language already knows |what is wrong. It can also be used in an unsafe way? O-ha. Sounds dangerous in my ears (given human behaviour in particular). I was so focused on winning against Putin, .. that i did realize this context. (Btw i like The Cures new song "Alone", after 14 years!, and its accompanying thrilling mega mega boom boom boom video.) P.S.: In the real world i would now, as the conservative and integer (up against the floating-point!) person that i am point "you" to C++, and simply pass a string object. But let us pass a reference so we gain compile-time non-NIL "meat" (vegan!!), and impressive state-of-the-art speed characteristics. Human behaviour can destroy everything: faster so with C++! --End of &lt;CAFH29tp4fZR7ct57F-BmyqoJwwRfHkSbiVPS1mj89e-_gzhsHQ(a)mail.gmail\ .com> Btw i hate these random message-ids, they reveal nothing! Like in all those rooms i never visit. I am all for the wonderful Klaus von Dohnanyi, now also 96 years old, and his saying "Ach bitte, sagen Sie nicht Chatroom, sagen Sie Plauderstübchen" ("Oh please, do not say chatroom, just say [little talk chamber][ʃtyːpçən]" [1] (needs scripting-enabled browser). [1] https://translate.google.com/?sl=auto&tl=en&text=Plauderst%C3%BCbch… --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Bakul Shah via TUHS &lt;tuhs(a)tuhs.org&gt; writes: Related: Ten years ago, Pascal Cuoq, Matthew Flatt, and John Regehr proposed "Friendly C": -- https://blog.regehr.org/archives/1180 Some of the concrete features proposed included: i seem to recall there have been other proposals in the vein of "Friendly C", but they're not coming to mind right now. Alexis.

Rik Farrow wrote in &lt;CACY3YMHzg+6U_zTuhMTORgfh_Kse6MTspaGDfuUjXb4vLvV9mw(a)mail.gmail.com&gt;: |On Mon, Sep 30, 2024 at 12:12 PM Steffen Nurpmeso  | || Never attribute to malice what can adequately be explained by || incompetence. | ||is the signature of Poul-Henning Kamp (whose email regarding that ||cstr list <snip> |This is the 'problem' with C/C++: it's not the language itself so much as |the people who are allowed, or forced, to use it. Many, if not all, of the |people on this list have worked with great programmers, when most |programmers are average at best. I saw some terrible things back when doing |technical sales support for a startup selling a graphics library with C |bindings. I came away convinced that most of the 'programmers' I was |training were truly clueless. I cannot comment on that, humans "get a good job with more pay you are ok", have interests here and there, have (unfulfilled) desires, problems with family or partner, aka "that sex machine", and so in the end one can be lucky if that was not Jeffrey Dahmer or something, and you do not end up as canned. "Or forced", yes! Here on this lists are (me aside) intellectual but especially witty people who love(d) their (likely) even-more-than-a-job, at the "top of the pyramid", Mr. McIlroy just again remembered an impressive scenario of how these people were (and are) self-driving up that spiral staircase with nothing but the help of their mind and a free library .. which was available for them. Other than that, you know, there are plenty of languages with plenty of support (syntax checks, sanitizers, "debug stuff"), far beyond vim(1), let that start with JAVA (documented pretty well right from the start as far as i know), and all the other options that arose since then, and in parts are used. I personally "go on the gums" if i have to work with OpenSSL, and image processing is no fun either, so it could be it was me who drove you down... (And complexity is never easy, i think, to noone.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)