uecker

In my experience, compilers are very good at this.

I agree that mixing signed and unsigned types creates friction. After trying to use unsigned for sizes and indices for a while, I changed my mind and now use signed types almost everywhere, except for modulo arithmetic and bit masks, and I found this removes all problems I had before.

I don't think the usual arithmetic conversions are very problematic, IMHO there is a lot of FUD about this. The rule is also very simple: "Operands are converted to the higher ranked type but at least to the rank of int, and to the signed type if it covers all values of both types and otherwise to the unsigned version." This is the complete rule.

I like the your final version, but it is a bit too clever for my taste.

I know. This does not make it a bad choice.

> Now your index variable is signed, which can cause problems when used in expressions due to C's conversion rules.

I don't see this. What problems would those be?

> ssize_t is a POSIX thing so you'd have to define it yourself on windows.

True. But I think "int" would be the right choice anyway in almost all case.

> If your type is 32 bit, you run into promotion problems and might even run into truncation problems.

What promotion problems? If your loop exceeds 2G than yes, you run into overflow (not for backwards loop though). But with a signed type you can automatically get a trap or diagnostic for overflow. This is far easier to debug and protect against compared to mistakes with unsigned types.

Sorry, I find the supply chain risks of Rust much more worrying than these memory safety issues. So how about we get rid of Rust? At least cargo is a problem.

You let the AI generate it. Apparently it becomes quite good at proving things. Here is a some effort: https://www.anthropic.com/research/formal-verification (but this is on generated RISC-V code)

If you let the agents mess with the code, there seems to be no fundamental reason to use a pure functional language in the first place. The point here is that it is proven correctly. This could be done for C or even assembly. Going to Rust makes no sense either, as this just adds restrictions which are unnecessary if you have a correctness proof.

Memory bugs are also just bugs. If you want to remove also others bugs, you need to formally verify, which soon AI and tools will also just do for you.

Exploring the design of a safe result type in C.

The difference is that the part we do not understand about QM is rather fundamental to its interpretation, while in classical physics it is more a problem of understanding its consequences in complex scenarios.

If one does understand quantum mechanics well enough to use it, then one also understands that there are aspects of it we do not fully understand.

I don't think so. In any case, templates are still worse to debug, so if the entire process has failed, then even more so for templates.

I do not want locked-down commercial apps on Linux platform with remote attestation. I want open-source tools from community maintained curated repositories that let me do what I want to do on my own hardware by combining those tools which should also be able to interact using open protocols. So no, I do not want to have software designed for the opposite, so I like neither Wayland nor flatpak nor systemd and if this what modern Linux is about I am happy staying with old Linux or something else.

Also the position in the original source code is tracked.

In fact, this enhancement should be doable. Please file a bug. But the answer why something is not done in a C compiler is usually: Nobody did substantial investments on it in the last two decades. So if you want to see improvements, usually one has to submit a patch.

Hey, I agree about your second sentence but I do not really see the first. Alone that I can directly inspect the result of the preprocessor makes macros easier to debug than templates in my experience.

I am not sure. I agree one should minimize macros in C, but for some things a small macro layer still beats the complexity of C++ and is not inferior in my opinion.

And for generic data structures one can also a very thin layer of macros around type-erased implementations.

They will have to get recycled at some point.

The history of the US would imply otherwise. In any case, Germany definitely needs immigration for economic reasons as the population is aging.

Perhaps the LLM can infer enough context from one function.

In the EU solar panels old have to be taken back by the vendor for recycling (as all electronic waste).

Yes, and this is true already without adding all societal costs up, which is why there is not much investement in nuclear.

Also one correction: It was Germany that get the wheels rolling regarding renewables, although China then took over.

BSD's generic macros are certainly older than C99 and I would not call this "a lot more effort". My macros are exploring a modern version of this, but people have been doing this for decades.

Compilers would just ignore the annex and whoever wants to implement it, can already do this. And I also think ACSL is too complex for what is needed and also not well integrated with the rest of the language.

You may think about this blog post from John Regehr about Fermat's Last Theorem: https://blog.regehr.org/archives/140

Ah right, they had improved that. Btw: Everbody can submit proposals to WG14.

The classification can not be done on the function level. There are two ways, either this is done using AI or using a SAT solver.

They globally derive the borrowing information for all pointers in the whole program by classifying the role of each pointer. If there is a way to do this in a way that makes the program safe, this is computed automatically using a SAT solver.

No language is safe, but I assume you mean memory safety in particular. Alternatives are to formally verify the C code to be memory safe or to add some memory safety features to C. Both certainly simpler and cheaper than rewriting everything.

Whether memory safety is really that important is also not clear. Most people get hacked because they run old software or insecure configurations. So a language such as Rust which creates more supply chain risks seems problematic.

It is interprocedural, but one obviously needs annotations for interfaces to libraries that are linked-in.

One example of a project wich goes in this direction is this work: https://www.sei.cmu.edu/projects/ai-powered-memory-safety-fo...

(I assume the AI is mostly marketing as it is not necessary)