uecker

I don't they are the worst (often hard or impossible to exploit) and also not the most common according to: https://www.cvedetails.com/vulnerabilities-by-types.php (despite likel…

The start of the thread was "The difference is every line of C can do something wrong while very few lines of Rust can." but this is an exaggeration of this kind.

I agree about what you write.. Also please note that I am not saying unsafe blocks are a bad idea. In fact, I think they are a great idea. But note that people run around saying "it is sufficient…

The issue is a memory safety issue, which Rust aims to protect against. But I am not saying Rust is bad. My issue is the complete unreasonable exaggeration in propaganda from "C is completely dan…

The bug that can lead to a violation of assumptions required for safety of the unsafe block can be elsewhere. One can hope that it is near the bloc, but there is nothing in Rust enforcing this.

Let's discuss this example: https://github.com/ejmahler/transpose/blob/e70dd159f1881d86a... The code is buggy. Where is the bug?…

In other words, somebody made an error somewhere.

It does not invalidate an argument that you do not want to talk about it. Regarding the second point: yes, you can then blame the "unsafe" part but the issue is that the problem might not be…

Yes, this discussion is about memory safety, but this does not invalidate my argument. There is no point in only auditing your code with respect to memory safety, so the argument that you can simply i…

If you think correctness is only about memory safety, only then you can you can "focus your auditing and formal efforts on just those small unsafe blocks". And this is a core problem of Rus…

If you limited wrong to "memory safe" and also ignore that unsafe parts violating invariants can make safe parts of Rust to be wrong.

Every C compiler I ever used will tell you that void( )(void ) is not convertible to void ( )(char ). If people still do it then they are a bit on their own. But how is this then different to Rust&#…

C does give a lot of low-level control, but it is still an abstraction - as it should be. Signed integer overflow is something were I personally like that it is UB, because I can turn on UBSan and f…

And issues in the unsafe parts, which could cause UB in the safe part.

You are confusing "the same" with "compatible" and maybe also with "have the same alignment and representation".

With GCC/clang can just add checking with -fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error. For my main software project, which is some numerical software for magnetic resona…

There good tools that help improving memory safety in C and I do not think Rust is a good language. Of course, the worst about Rust are its fans.

The good news is that MSVC has C17 support (still missing important optional features, but at least some progress).

You can still access the size which is what the parent was asking for. And please tell me how you would try this on an ISO compliant compiler for D.

You need to take the address of the array instead of letting it decay and then size is encoded in the type: int foo(int (*a)[6]) { return a[5]; } int main() { int a[3]; return foo(&a);…

Oh, it also work for runtime length: https://godbolt.org/z/PnaWWcK9o

Most of us liking a good language just did not use MSVC. I do not think many people who appreciate C's simplicity and stability would be happy with C++ / Rust. Zig is beautiful, but still …

UB is does not automatically make things unsafe. You can have a compiler that implements safe defaults for most UB, and then it is not unsafe.

Right. Also it might it sound like array-to-pointer decay is forced onto the programmer. Instead, you can take the address of an array just fine without letting it decay. The type then preserves the l…

Function overloading is a feature that makes code less self-documenting without providing any meaningful value. Operator overloading is more interesting, because you can build you domain language wi…

I don't know, I never found the "proper abstraction" be more than irrelevant syntactic sugar. And the cost of C++ is that you end up putting everything in the header (IMHO the biggest d…

The traditional use case are circular linked lists or similar data structures. struct foo { struct foo *next; } x = { .next = &x };

And yet, coding styles do not prohibit it and there is no compiler that has a warning.

I would much prefer a safe C to Rust.

I actually like GCC's nested functions a lot, although an implementation with function descriptors would be much better.