>>107901208
(1/2)
>i think c is completely unsuitable to be used when working in a big team
Funnily enough even though I'm a memory safety guy I wouldn't go that far, though of course all the implicit invariants hurt far more when there are many people. libcurl does kind of OK nowadays, only half their vulnerabilities are from memory safety vs logic bugs (which seems like a decent proxy for bugs overall), even though they accept drive-by contributions from non-experts like yours truly.
>theres fucking cargo, which thank god i heard is forbidden in the kernel, but is not forbidden in core utils i think.
The Rust coreutils kind of suck but it's because the code is managed by unopinionated people with low standards. Without cargo it'd be worse because the libraries they pull in meet a higher bar than the code they write themselves. Some aspects of it are actually managed pretty well but it's got dysfunctions I've never seen anywhere else because it's actually a hundred different programs in a trenchcoat. Very odd project.
>its nto something that gets broken in c very often
C changed a lot early on: the += operator used to be spelled =+, static variable declarations didn't use = , you didn't need forward declarations because everything was sort of assumed to be int-shaped. Modern compilers can't even parse old C code.
But that's actually not what I meant at all, I'm talking about library interfaces. Suppose you have a function:
char *foo(char *s, char *t);
The return value has the same lifetime as s and the lifetime of t doesn't matter. The borrow checker correctly infers this.
Then you change something about the definition, and the borrow checker's heuristics fail to infer it, and now it says that the return value's lifetime is coupled to both s and to t.
Now callers of foo might get broken because foo changed its lifetime signature. They might no longer pass the borrow checker. (This is a bigger deal if the borrow checker blocks compilation of course.)
