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)

Dan Cross &lt;crossd(a)gmail.com&gt; wrote: Following the letter, rather than the spirit, of the standard? Something similar happened with so-called strict aliasing, when the compilers started assuming pointers to incompatible types as always pointer to different non-overlapping locations: See, e.g.: <https://www.geeksforgeeks.org/strict-aliasing-rule-in-c-with-examples/> Linus ranterd about it: <https://lkml.org/lkml/2018/6/5/769> I am a bad one as well, to have liked some things in Martin's books /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor Dijxtra, nor Knuth, but why a charlatan?

On Mon, 18 Nov 2024, Luther Johnson wrote: I feel like most of the changes to C after C89 were a waste. Apart from stdint.h, I mostly keep to coding in strict C89. -uso.

On Mon, Nov 18, 2024 at 03:00:22PM -0000, Anton Shepelev wrote: Snippet from a Makefile for a small university exercise of mine from decades ago: ---- snip ----- # flags for debugging DEBUG = -g -DDEBUG # complain about everything suspicious ANAL_RETENTIVE = -ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Werror -Wshadow -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Waggregate-return -Wmissing-declarations -Wnested-externs -Winline # use this for development CC = gcc ${DEBUG} ${ANAL_RETENTIVE} ---- snip ----- Yes, I was keenly aware that I wasn't exactly "God's gift to C Programming" and tried to get as much help from the compiler to avoid obvious mistakes as possible. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison

At 2024-11-18T14:55:55-0000, Anton Shepelev wrote: I think that's an overgeneralization. The Ada language, for example, drew much wariness and even criticism for being funded by the U.S. Department of Defense, probably the most profligate spender in the history of mankind,[1] and at the same time was condemned for being too hard a language to grasp (too "big") and too hard to write a compiler for. Further, I would argue that Ada was indeed an excellent language, certainly for its time and arguably still. But it was not easy to acquire by programmers who took an absolutely slovenly attitude toward data type discipline, a characterization that fits many pre-ANSI C programmers perfectly. Perhaps those who learn how to manage data types using C as their first language suffer irrevocable brain damage, and are fit subjects for pity and mockery. You won't find _that_ opinion in the Jargon File. Regards, Branden [1] https://www.npr.org/2021/05/19/997961646/the-pentagon-has-never-passed-an-a…

I think both Ada and VHDL, started formally, and proceeded formally. I don't have experience with either of them, but from the outside they appear to be competent and rational. I was mostly commenting on early C and Lisp (or Verilog is another example, although I think Verilog has stayed pretty close to the original versions), of being less formal, with more implicit defaults, that just do pretty much what you would expect them to, which gives a great deal of concise leverage. Some of that gets lost when the language gets more formally "correct" or "complete", or you have to be more verbose, or maybe just stay away from certain constructs altogether, if you're not willing to qualify to the nth degree. And so, the later variants become less useful (to me) than the original versions. It's true that the first, informal versions of these languages, do require us to understand, and buy in to, the mindset of the language inventors. But with the later versions, you have to devour 1000 pages of detail from the standards committee. Which gets us to working, productive code faster ? Some prefer one path, some prefer another, but I like to learn the point of view and approach of the original authors, to me it's like reading a novel compared to reading an encyclopedia. On 11/18/2024 09:52 AM, G. Branden Robinson wrote:

"Appeal to Authority", or "Argument from Authority", one of the fallacious argument methods. I think there are many "experts" who learn just enough about a topic to write a book about it, the idea seems to be, to become an "authority" on a topic, to sell more books and gain more authority and notoriety. I've read many good books by brilliant authors who not only could write about certain topics, but were actually some of the inventors and developers, who then explained it all to us so we could make more things practically work. And then there are slapped-together books of technically trendy slogans and simplistic contrived examples. I like to read books in the former category, the latter, not so much. We can tell the difference by whether the books give us anything we can use - and this is usually more in the realm of ideas, rather than code snippets or "design patterns". The way I like to think about things, anyway. On 11/21/2024 06:53 PM, Dan Cross wrote: