161–170 of 225 posts
It's interesting that C has managed to remain relatively stable whilst everything else has ballooned in size. I spend most of my time writing C# and it has become quite large. I wouldn't want to pick it up from scratch now.
“My perception of the second sort of C programmer is that if they've moved to any more recent mainstream language, it's probably Rust.” If you are the first type, you likely get the second type’s taste wrong. Rust is very very different from C both in terms of syntax and philosophy.
Rust is from a different language family, but I think it still fits a taste of "low-level control, not OOP, not C++". I know many people see "complex with angle brackets" and equate Rust more with C++, but I disagree and think it's still closer to C — I can convert C libraries 1:1 to Rust, but C++ libraries hit an impedance mismatch and are really hard to rustify.
Things have a drop-scope. There are hidden initializations. Boxing is required for many things including dynamic dispatch in error handling. The tendency to use FP-like one-liners. All that mixed with funny syntax that hurts C developers eyes.
A lot of "no-go" in C land (at least for me), that makes really hard to learn and to move definitely into Rust (again, at least for me)
Earlier quoted context omitted.
> I also don't like how UB turned into “a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs.” You can have a language where all the behaviour is defined but in my experience most programmers who whine about this in C are just as unhappy because what they actually wanted was DWIM. In a language with defined behav…
4u - 5u is not undefined behavior in c; unsigned arithmetic overflow is defined to wrap around, in both directions assigning -1 to an unsigned variable has never been undefined behavior either, but implementation-defined behavior (see §6.2.1.2p3 in iso c90 or §6.3.1.3 in c99 and c11); decent compilers like gcc define it to do the obviously correct thing (see https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.…
If you give up the aggressive optimisations then C is even less competitive with modern languages, so you're basically arguing that it's acceptable to have code that's harder to write, more buggy and with worse performance just because that's how you'd have done it 30 years ago. At that point you're talking about a retro hobby.
Earlier quoted context omitted.
I assume this was a logic error, that is, the code as written was a valid C program that didn't do what you meant. In that case this could have been caught with more careful unit tests, which would have exercised the erroneous condition, and potentially with fuzzing to excite corner cases. C is... not great for either of these.
I don't know why you say that C is bad for exercising error conditions or fuzzing. In my experience, it's the best at those.
Earlier quoted context omitted.
Oh wow, someone should alert the Linux kernel maintainers. Do you want to tell them that it’s impossible to write correct C code? And the rust compiler team, too. After all, if nobody can write safe assembly then whatever they’re doing is either unsafe or magically gets the computer to understand rust directly. Or are they relying on LLVM for their code generation? I forget what language that’s written in, but nothin…
Indeed, https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...
Earlier quoted context omitted.
Indeed, https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...
If the existence of C cves in the kernel proves that it is impossible to write correct C, then by the same token any cves in any rust code prove the same thing about rust. This is such a lazy way of arguing. Say something about why the tradeoffs favor a more restrictive and less performant language or don’t, but don’t dismiss the work of many thousands of C developers that runs most enterprise systems with a knowing…
https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...
https://security.apple.com/blog/towards-the-next-generation-...
https://www.chromium.org/Home/chromium-security/memory-safet...
https://security.googleblog.com/2022/08/making-linux-kernel-...
Σ (memory corruption) + Σ (logic errors) ≥ Σ (logic errors)
So by reducing in 70% the costs of fixing the errors caused by those thousands of experts, as validated by the above reports, there is already a considerable reduction in software development expenses.
Lets see how serious those developers get to be around security issues, when liability finally takes off.
Earlier quoted context omitted.
If the existence of C cves in the kernel proves that it is impossible to write correct C, then by the same token any cves in any rust code prove the same thing about rust. This is such a lazy way of arguing. Say something about why the tradeoffs favor a more restrictive and less performant language or don’t, but don’t dismiss the work of many thousands of C developers that runs most enterprise systems with a knowing…
So you want something more serious, https://msrc.microsoft.com/blog/2019/07/a-proactive-approach... https://security.apple.com/blog/towards-the-next-generation-... https://www.chromium.org/Home/chromium-security/memory-safet... https://security.googleblog.com/2022/08/making-linux-kernel-... Σ (memory corruption) + Σ (logic errors) ≥ Σ (logic errors) So by reducing in 70% the costs of fixing the errors caused by those…
Earlier quoted context omitted.
Indeed, https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...
If the existence of C cves in the kernel proves that it is impossible to write correct C, then by the same token any cves in any rust code prove the same thing about rust. This is such a lazy way of arguing. Say something about why the tradeoffs favor a more restrictive and less performant language or don’t, but don’t dismiss the work of many thousands of C developers that runs most enterprise systems with a knowing…
the point that is being made (obliquely) is that manual memory management is not possible for human beings to do effectively at scale
at scale means across a broad demographic of programmers, working on a broad set of programs
if you wanted performant and portable then C was all you had for a long time, and there is a lot of good software written in C, but that does not mean that it is a good tool in perpetuity
strcpy and pointer arithmetic are basically not possible to get right
we need to move beyond this very low level of abstraction
Earlier quoted context omitted.
I don't know why you say that C is bad for exercising error conditions or fuzzing. In my experience, it's the best at those.
It doesn't come with either capability, so you're adding third party tooling to get these working.
Earlier quoted context omitted.
> it's not possible for human beings to write correct C code, measured over time I don't disagree [1], but remember that Rust can be unsafe too. Async is not a panacea, and it's confusing. And the `unsafe` escape hatch is still unsafe. > you have a professional obligation to use a higher-level language, with stronger guarantees Oh? So we have professional obligations now? For FOSS? News to me. I don't get paid for my…
Ask any experienced C developer and they'd all say "I write excellent C compared to all C programmers out there."
I think the proof is in the pudding here. I can't imagine using a messaging client or an email client written in C, and also there isn't much that is written in C anymore even if I wanted to: you're looking at Swift/Java/Kotlin/TypeScript/JavaScript/C#/Vala/Dart/Rust/Go, and maybe C++.
Is anyone writing production servers in C these days? It feels like they're 100% Go and Rust.
There are notable exceptions, in particular I'm thinking about OpenBSD. I think OS dev is a pretty niche area though, especially when you're talking about OpenBSD's wide platform support, so I think it's more the exception that proves the rule than anything.