51–60 of 98 posts
Earlier quoted context omitted.
C is not inherently unsafe. Sure, it hasn't "memory safety" as a feature. But there are loads of applications considered safe written in C. An experienced C programmer (with the help of tooling) can write safe C code. It is not impossible.
That would explain all the vulnerabilities in systemd and Linux. They just aren't experienced enough. Linus needs to get in touch with an expert.
"But Ghostscript’s PDF interpreter was, as noted, written in PostScript, and PostScript is not a great language for handling error conditions and recovering." Isn't C, their chosen replacement of PostScript, also particularly bad at this?
I'd say a language is bad at error handling if it doesn't let you check if a procedure failed or not. What C does it that it compiles even if you ignore this, which is a different issue. Java, Rust, etc. wouldn't compile if you totally ignored it, but you that doesn't mean you have to do proper error handling, beyond satisfying the compiler/type system.
Earlier quoted context omitted.
It looks like it needs to interoperable with the rest of their codebase which was already written in C > The new PDF interpreter is written entirely in C, but interfaces to the same underlying graphics library as the existing PostScript interpreter. So operations in PDF should render exactly the same as they always have (this is affected slightly by differing numerical accuracy), all the same devices that are current…
That is not an argument at least for rust since its super easy to consume and offer a C interface. I think it's more of a shift in mentality that needs to occur.
Another issue is general subtle brokenness of rust tooling on anything that is not linux on amd64.
Earlier quoted context omitted.
> this means that using, say, a dictionary means that quite a bit of the implementation gets hard coded into every site that uses the dictionary I don't understand this part of your comment. There's nothing preventing you from designing a nice well-encapsulated map/dictionary data structure in C and I'm sure there are many many libraries that do just that. I do agree though that having such basic data structures in t…
Lack of generics will do that, unless you consider that blindly casting `void ` all over the place counts as "well-encapsulated". Even with macro-soup designing a good agnostic dictionary implementation for C is rather challenging. Linked lists are okay* if you use something like the kernel's list.h, but even then it's macro-heavy and has its pitfalls. In my work as an embedded developer I still use C a lot and it's…
Personally I haven't used straight C in years and would never choose it over C++ unless platform constraints required it, but a vast amount of very complex software has been and continues to be written in C, including all the widely used OS kernels, so I don't find it very surprising that a new feature in a very old piece of software would be written in it.
Earlier quoted context omitted.
size_t key_size, void *key
> nice well-encapsulated ... > void *
Earlier quoted context omitted.
C is not inherently unsafe. Sure, it hasn't "memory safety" as a feature. But there are loads of applications considered safe written in C. An experienced C programmer (with the help of tooling) can write safe C code. It is not impossible.
SQLite is the most stringently developed C code I'm aware of--the test suite maintains 100% branch coverage, routinely run through all of the sanitizers, and it is regularly fuzzed. It still accumulates CVEs: https://www.sqlite.org/cves.html .
Earlier quoted context omitted.
> nice well-encapsulated ... > void *
Type safety and encapsulation aren't the same thing. Encapsulation is about hiding implementation details from the user of an API, which is what the comment I originally replied to was claiming you couldn't do in C.
For example if I want to store a __int128 on a 64-bit machine I'll have to deal with stuff like memory allocation and lifetime myself, when the data structure should do that.
Earlier quoted context omitted.
SQLite is the most stringently developed C code I'm aware of--the test suite maintains 100% branch coverage, routinely run through all of the sanitizers, and it is regularly fuzzed. It still accumulates CVEs: https://www.sqlite.org/cves.html .
Are you aware of a way to develop fault free code? Please share this knowledge then, please.
That's not a helpful answer, but it's basically the same thing you're doing--redefining memory safety vulnerabilities that would be precluded entirely by writing in memory-safe languages as programmer faults.
Earlier quoted context omitted.
SQLite is the most stringently developed C code I'm aware of--the test suite maintains 100% branch coverage, routinely run through all of the sanitizers, and it is regularly fuzzed. It still accumulates CVEs: https://www.sqlite.org/cves.html .
Are you aware of a way to develop fault free code? Please share this knowledge then, please.