Rust things I miss in C
people.gnome.org
people.gnome.org
- Raspberry Pi 3
- 1⁄2-sized breadboard
- 4GiB microSD card
- microSD card USB adapter
- CP2102 USB TTL adapter w/4 jumper cables
- 10 female-male DuPont jumper cables
And I had to buy:
- 10 multicolored LEDs
- 4 100 ohm resistors
- 4 1k ohm resistors
- 10 male-male DuPont jumper cables
Specifically this kit: http://tinkersphere.com/raspberry-pi-orange-pi-boards/1538-r...
Is this a hack that should not be allowed? I don't think so. Every processor made (that I'm aware of) in the last 30+ years has used 2's complement arithmetic. I don't think overflow is a bad thing, I think C made a mistake in calling it "undefined". They had to because when the language came along there were other options fresh in peoples minds.
I've also worked on systems in asm that had saturating arithmetic, and that has it's own nice use cases. My preference is still to have the rollover. People can implement bounds checking when they need to.
:)
struct Angle(i16);
impl Add for Angle {
type Output = Angle;
fn add(self, rhs: Angle) -> Angle {
Angle(self.0.wrapping_add(rhs.0))
}
}Of course, it might make sense in the embedded space to do so.
I like rust's approach that you can explicitly decide to use overflowing arithmetic if you want, otherwise it triggers a runtime error in debug mode. That alongside with the checked_ variants make it very easy to deal with potentially overflowing code whereas in C it's a minefield, it's not difficult to trigger an UB while trying to defend against an other UB. Ask a beginner to write a "checked_add" function in C (no Stack Overflow allowed) and see how many bugs and UB you can spot.
On the other hand advocating for implicit wrapping overflow all the time sounds risky to me. In my experience there's only a very tiny subset of operations where an overflow is desired and wouldn't lead to a bug.
not by default, no
I personally think it's a good thing to only allow overflows when explicitly allowed.
1. overflow is a "program error"
2. If `debug_assertions` are enabled, then overflow must panic
3. If overflow does not panic, then it must two's compliment wrap
This leaves the door open to always requiring a panic someday in the future, if performance gets there.
It is very risky to have different behavior on such things in test and production.
Maybe Rust++ will fix this, someday :p
(Or, once people have the tolerance for the performance degradation and we can turn it on in rustc, exactly why we specified it the way we did.)
(Or, you can tweak it to include this behavior in release mode; always an option)
Few things are harder to debug than things that pass the tests but fail in production and anything that inserts behavior like that should be avoided like the proverbial plague.
If you're already of a mindset to have a Rust++ then you are missing the point, Rust quite possibly has a window of opportunity to displace C but for that to work at a level where it succeeds rather than as an 'also ran' you will need to religiously avoid repeating the past.
Rust is not a religious language, regardless of what some people may think. It's even in the name, which evokes something practical, well used, and a bit worn.
> If you're already of a mindset to have a Rust++
Language design is about trade-offs. Do I think Rust is generally an excellent language? Yes. Does that mean that I believe we have solved programming languages, that there will never be a language better than Rust? No. Someday, Rust will be the old incumbent, and a new language will overtake it. That's how progress works.
In the end, as I said, this was a very tough call. In the end, we decided to be hardline[1] about one thing, and one thing only: memory safety. Does Rust care about program correctness? Absolutely! Does it care about it as much as memory safety? It does not. There's several PLT features that could help improve program correctness that are not in Rust. They're not in it because it's a balance. Including them would harm several of our other objectives for the language.
This RFC was one of the most discussed at its time. 160 comments! https://github.com/rust-lang/rfcs/pull/560
We would have loved to say that it's always on, but that's just life. Nothing is ever perfect. Rust certainly is not.
1: note that I said "hardline" and not "religious" here even; even Rust's most sacred principle, memory safety, has a keyword built into the language that lets you subvert it!
The reason C has the bad reputation it does is because it makes performance over correctness trade-offs that we have come to realize that are not just far from ideal, they are fundamentally wrong.
And now Rust, the supposed replacement of C is going to make different trade-offs some of which are rooted in exactly the same performance-over-correctness decisions that gave C its bad name.
I completely get why that RFC had as much input as it did, it's akin to the Python 'whitespace' decision, it's a fundamental thing and to get it wrong will turn off a lot of people from what you are building.
On another note, integer overflow has been the cause of the same kind of issues that unsafe use of memory is associated with:
http://www.kb.cert.org/vuls/id/945216
That makes it a problem in the same class and frankly I'm quite surprised that Rust would take performance over safety in this matter, in my opinion good slow code is always better than faster but possibly incorrect code.
This is what I mean by tradeoffs: if Rust had significantly worse integer performance, it would also turn off a lot of people from what we are building.
> On another note, integer overflow has been the cause of the same kind of issues that unsafe use of memory is associated with:
From a quick read of this CVE, this requires memory unsafely too.
If you could manage to produce a situation where overflow causes a memory safety issue using only safe code, then we'd switch.
An integer that has wrapped gets passed into a piece of unsafe Rust code that was otherwise bullet proof, exposing a vulnerability where otherwise the program would have abended much earlier when the overflow happened.
The very best spot to trap an error is where it is first initiated, any cycles after that point are being run in what is essentially an undefined state which will sooner or later - hopefully sooner, but sometimes much later - result in either incorrect behavior, a security issue or in the most benign cases a crash. To willfully postpone the discovery of the error introduces the risk that the error will never be caught at all, the program will continue to run and will produce bogus output, spill out your state secrets or worse.
First make it work correctly, then make it fast. If you're going to worry about speed before you have it working you are falling headlong into the premature optimization trap, a trap that C programmers the world over unfortunately have extensive experience with and that I thought - perhaps mistakenly so - the Rust crowd was trying to address.
Btw, Swift seems to get this right, I wonder what their secret sauce is.
Yes. That still requires unsafe code. All bets are off there. You should be validating everything with regards to unsafe. There's tons of ways unsafe can go wrong; this scenario is a drop in the bucket. The bug is fundamentally in that unsafe code, not in the overflowed integer, as unsafe code is not supposed to expose memory unsafety; you could have passed a zero or a -128 or whatever manually, and it would still have caused this.
> The very best spot to trap an error is where it is first initiated,
I agree completely!
> I thought - perhaps mistakenly so - the Rust crowd was trying to address.
If you believed that Rust was about program correctness above all else, then yes, you were mistaken. As I said above, our priorities are memory safety above all else. Correctness is certainly up there, but when the rubber hits the road, hard choices have to be made.
Btw, and on the same note, I always felt that it should be possible to generate a fault on an unexpected carry so I see this as much as a CPU issue as a programming language issue.
In that case, that piece of unsafe code would have a bug, which would be a bug regardless of whether overflow happened. The contract of unsafe code is that it must not expose undefined behavior.
For example, vector indexing is implemented with unsafe code, but the unsafe code performs bounds checks, so it doesn't matter whether an overflowed integer was passed in as the index.
> Btw, Swift seems to get this right, I wonder what their secret sauce is.
Their "secret sauce" is not having the same performance goals (which is not a criticism of Swift).
Another reason integer overflow can turn into a vulnerability is because it's Undefined Behavior, and when encountering Undefined Behavior the compiler can do anything, including eliding bounds checks. Rust (and C with -fno-strict-overflow) prevents that by making integer overflow have a defined behavior.
> http://www.kb.cert.org/vuls/id/945216
That bug, like nearly all other security bugs relating to integer overflow, relies on the lack of bounds checking in C. In a language with bounds checks, that bug would not have been dangerous.
Ideally you would run your tests in both debug and release modes, though. :)
Can you expand on what that means to someone who hasn't used Rust yet? Does it mean a third thing distinct from (2) and (3)? Or is it that (2) and (3) are the things that might happen as a result of (1)?
Mostly, it means "this is wrong but it is not undefined behavior".
> Or is it that (2) and (3) are the things that might happen as a result of (1)?
Yes, this.
This is similar. "program error" means "You're not supposed to do this. But the compiler will not assume that you've not done this; it has your back. If you do this your program will exhibit defined behavior. Perhaps undesired behavior (panicking, or segfaulting), but the behavior will be defined."
DSPs often use saturating overflow IIRC
I've used them, and used that feature. It was an option that could be turned on and off. The basic arithmetic was the same as any other CPU unless that was enabled.
This caveat sounds an awful lot like undefined behavior ;p
FWIW that's not quite true, Rust will panic on overflow in debug but can (and currently does on all platforms I think) allow them in release. They're not UB though, they're defined as 2's complement.
> In my embedded work we use that all the time. We represent angles as a int16_t or uint16_t where you can add and subtract angles and never have to worry about a discontinuity at 2pi because 2pi=65536.
> Is this a hack that should not be allowed? I don't think so.
Rust provides APIs to make these behaviours explicit decisions rather than implicit hacks: https://doc.rust-lang.org/core/num/struct.Wrapping.html, https://doc.rust-lang.org/std/?search=wrapping_, https://doc.rust-lang.org/std/?search=saturating_ (and https://doc.rust-lang.org/std/?search=checked_).
> People can implement bounds checking when they need to.
Being unsafe by default always ends up in tears. Checking Mitre, just this year there have already been 11 public CVE for integer overflows.
TL;DR the decisions made in the design of Rust seem reasonable.
Click "release" and then "asm", you'll see that they are compiled to the exact same thing.
Some tame examples:
- When retrofitting >4GB file support into an existing program.
- Counting in milliseconds (e.g. GetTickCount overflows every ~50 days - if that causes you a crash, it will be a very nasty rare bug, to the point where windows checked builds actually advance that time by ~49 days to make it repro faster: https://msdn.microsoft.com/en-us/library/windows/desktop/ms7... .)
A less tame example:
- Any deserialization that involves untrusted sources. (So, all deserialization - there's a reason your IT department doesn't want you opening random PDFs!)
Say you have an array. So you allocate "sizeof(Element) * elements" bytes. Attacker picks "elements" such that this overflows to a small/near-zero value - which successfully allocates - does a similar amount of IO, which also succeeds - then tries to loop over "elements" number of array elements, which didn't overflow without the multiply, and is now reading uninitialized memory.
At minimum this is a potential denial of service attack (just read until you hit an unmapped page.)
But it's easy to see how this could be (ab)used for data exfiltration as well in a typical C codebase. Say this is a simple echo or chat server - it's going to write whatever it reads to someone, and won't stop until it crashes (if it crashes). That uninitialized memory might be private messages to other users... or it might be database credentials, or worse.
And this chat server probably copies that data it read around - so now you've got potential buffer overflows writing data. In the old days, you could use this to stomp x86 instructions with your own - pwned! Nowadays you have to use slightly more complicated techniques like ROP chains and figuring out ways to defeat ASLR - but the fundamental potential is still there.
It's worth noting that panicing doesn't actually fix the potential denial of service attack. But it probably makes it easier to figure out what's going on when fuzzing for such problems, makes unintentional overflows clearly bugs to be fixed rather than "eh whatever's" to be ignored, and helps prevent the more serious variations on that attack.
A space error: 370.000.000 $ for an integer overflow https://www.viva64.com/en/b/0426/
Not sure I get your trick, 2pi=6.2832 so I don't see how you avoid accumulating errors this way.
Yep. This is a hack that should not be allowed.
If yo want to use it, you should create your own type, with explicit modular arithmetic. Not try to ride architectural dependent assumptions.
The operators, such as +, panic on overflow in debug buids and wrap as two's complement in release builds.
As methods you get:
1) Two's complement wrapping (even in debug builds)
2) Saturation
3) Overflow checking (these return Option<T>
As it's a relatively common need, there's also a wrapper struct for this one: https://doc.rust-lang.org/core/num/struct.Wrapping.html
The mistake of the C standard was not having it "Platform dependent", rather then "Undefined". The difference is a big deal. Since overflow is undefined the optimizer is allowed to assume it never happens and therefor optimize away things, even though the behavior is defined on all CPUs known to man.
Ideally you'd be able to specify which mechanism you wanted for arithmetic as a property of a type, so you could have int_saturating and int_wraparound and int_nooverflow in the same code with the compiler preventing you from combining them by mistake.
C made it undefined because at the time of its manufacture twos-complement had not quite comprehensively won. There were still a few ones-complement systems in the 80s. https://en.wikipedia.org/wiki/UNIVAC_1100/2200_series
https://people.gnome.org/~federico/blog/docs/fmq-porting-c-t...
"Rust revived my interest in maintainership. It is very empowering to finally have a good language that I can use at the level of the stack where I work."
/// Multiples the specified number by two
///
/// ```
/// assert_eq!(multiply_by_two(5), 10);
/// ```
fn multiply_by_two(x: i32) -> i32 {
x * 2
}
If you treat your program (and your problem) as math, then it is necessary to explicitly define all its boundaries. However many (most) problems in real life are not strictly math problems due to their nature of ambiguity. The ambiguity has its physical source of unknown boundaries. For example, you may think you only need 32-bit integer and you may be sure of it today, but your assessment may change in the future. Similarly, you may think today you should use arbitrary precision and the constant boundary check does not matter, but it may matter some day. In the effort to eliminate undefined behavior, we are projecting our ideas from real world onto math realm. That projection may be quite lossy.
I am aware that the actual compiled program is always well defined and can be a perfect mathematical object, but it's source as a language do have ambiguity -- e.g. compiler implementations and undefined behavior. Ambiguous language sometimes can express ideas better than a mathematical language -- if we treat the legacy of our code more in its source rather than in its binary.
I didn’t know you could do that. I might need to go back and see what I can simplify with that trick.
note: `my_func` must be defined only once in the value namespace of this module
Which sometimes I miss
However, that's a fair amount of boilerplate for the feature, so I highly doubt it would pay off to use that pattern to e.g. convert Erlang code that makes heavy use of function-declaration pattern matching.
Additionally, a lot of the true power of Erlang's dispatch-plus-pattern-matching is because of its runtime pattern matching (e.g. http://puredanger.github.io/tech.puredanger.com/2008/12/30/p...). You can't do that in function signatures in Rust; you can only match on things known at compile time.
So if you were converting Erlang that made heavy use of this, you'd have to pull apart the compile-time-checkable (e.g. a function can be called with a string or a number) parts of function signatures, convert them into trait-based polymorphic dispatch locations, keep track of the runtime-checkable parts, and then convert them into 'match' statements or conditionals and make sure the right match code got run in the right trait-based dispatch locations. I suspect, past a pretty low number of functions making use of this, Rust code would either get very duplicated (if you have a separate trait method for each function name,argument-types tuple), or very tricky to deduplicate if you wanted to use the same trait methods for functions with the same argument-types signatures, but only run certain match code depending on the specific function/pattern that was called.
That would work, but if you did it naively/formulaically, it would make for less-than-readable code, I think.
TL;DR you can robotically implement the Erlang pattern in Rust if you want. You can hit a square peg really hard into a round hole and shave the corners off if you want, too.
This guy does a pretty good presentation on Polymorphism in Rust vs C++: https://www.youtube.com/watch?v=VSlBhAOLtFA
So security conscious C++ developers tend to use enum class, string, vector and array classes, RAII, iostreams, wrapping data access in classes with invariants,...
Developers with more C oriented mindset, tend to just code away like "C with C++ compiler" programming style.
Hence the need being discussing since the last three CppCon, to stop using C style programming in modern C++.
CppCon 2015: Kate Gregory “Stop Teaching C" - https://www.youtube.com/watch?v=YnWhqhNdYyk
CppCon 2015: Bjarne Stroustrup “Writing Good C++14” - https://www.youtube.com/watch?v=1OEu9C51K2A
CppCon 2017: Bjarne Stroustrup “Learning and Teaching Modern C++” - https://www.youtube.com/watch?v=fX2W3nNjJIo&t=2s
Of course, preventing copy-paste compatibility with C, already solves many of those issues from the get go.
The way I've seen it described is 'C with more convenient comments'.
What makes Rust a joy to program in is as much what it won’t let you do as what it will.
It doesn't have Rule of Three (or Five), it doesn't even have constructors. No SFINAE surprises ("templates" work like Concepts which are promised, but not in C++ yet). No headers. Pointers are "smart" by default and moves work without explicit std::move. "Panic safety" is less taxing and needed less often than exception safety. You can pass objects by value without accidentally truncating them, etc., etc.
C++ can do a lot of nice stuff, and even a lot of it quite safely, but I feel like it's going to backstab me every time I forget about some obscure rule, and it's going to be my fault for not knowing it. In Rust I can be confident that if it compiles, it's good.
Using JS for comparison.
Example, this code in JS
function decode(path){
try {
return parse(path);
} catch (err){
throw err; // rethrow
}
Could be compacted into this using try! macro or "?".
pub fn decode(path: &File) -> Result<Image>{
try!(parse(path))
For error propagation, I could easily consume the error of a third-party lib, and convert it into my own using the From trait:
/// Convert std::io::Error to RasterError::Io
impl From<IoError> for RasterError {
fn from(err: IoError) -> RasterError {
RasterError::Io(err)
}
Where as in JS, I would have to write a lot of if else if I want to convert a third-party package's error into my own error.
if( error.name === "IoError" ){
let err = new Error(error);
err.name = "MyError";
return err;
...
} parse(path)?
!> Reading the POV-Ray code source code for the first time and learning how to do object orientation and inheritance in C.
But https://github.com/POV-Ray/povray is all C++... It even says "Written in C++" on the Wikipedia page. Was he talking about some other source, maybe some older version?
Edit: [1] Here is a discussion about this topic from 2012. It seems that POV-Ray was ported to C++ for version 3.7.
[1] http://news.povray.org/povray.programming/thread/%3Cweb.4f01...
Now I feel the need to use that everywhere...
I learned using that and if this pattern matching pattern (heh) is indeed in there, I must have overread it...
> you just implement the [Drop] trait and that's basically it.
Is that what I was missing? could I have done that and not had to deal with lifetimes?
* An object can only have one owner.
* When giving a reference away from an object, the reference has a lifetime that makes sure the reference doesn't outlive the owner.
* You can either have one mutable reference >>or<< arbitrary read-only references.
* An owned object must be denoted mutable to be mutable, otherwise it is read-only.
The problem is in being able to put together a program that the compiler does not complain about. It always seems like you have to "feel" your way around by trying different things like a jigsaw puzzle rather than having a "canonical" way to do things that fit the lifetime/ownership model. Maybe there are more canonical ways based on people's experiences nowadays and maybe this problem is due to approaching solving things using a C (or other language) mind-set. It seems like learning these ways to avoid the Rust compilers errors related to lifetimes in any complex program takes longer than in other languages.
> It seems like learning these ways to avoid the Rust compilers errors related to lifetimes in any complex program takes longer than in other languages.
Opinion is split here. Some people prefer that C and C++ let you "get it slightly wrong" for a while, so you learn more incrementally. Others prefer that the Rust compiler tells you exactly what you've gotten wrong, so it can help you figure out what to learn about. I suspect which works better for you depends on you.
For me there was a gap between reading the Rust book and applying the knowledge. While reading I thought "that's easy" but later on "oh shit, the compiler complains all the time". If you make it past that point – which takes for most non-novice programmers around three weeks – then Rust becomes a very powerful tool to you.
It depends with which concepts someone is already familiar. To me the only really new concept was the lifetime and ownership one, all others have just a different syntax plus here and there some extra goodies. As example, when I saw the match keyword I thought "cool, Rust has a keyword for guards".
I learned Rust shortly after 1.0 was released. The real obstacle for me to overcome was to build a mental concept of what Rust is. Something that wasn't really communicated while reading the first pre-release Rust book.
You have to read a lot to get an idea of Rust, it should be the other way around – a common mistake done by almost everyone teaching something. Ideally the first chapter would be a buzzword free, Rust code free chapter about how Rust works superficially and why there is a need for yet another computer language. It should describe what kind of tools and concepts in Rust exist and which problems they solve. This is better than introducing somewhat complicated concepts/tools and trying to explain how they fit into the big picture at the same time.
Ideally there would be an introduction like this:
A program needs a structure, variables, control flow, tools... blablabla... this leads to some common problems [some easy examples] and [this] are some concepts Rust invented/uses to solve them.
In later chapters the abstract ideas would be "converted into Rust". Also don't go too much into detail. I don't think for example that a representation of the memory layout of a vector helps much. At first I just need to know there is a thing where I can put objects of the same type into, how it is implemented is not that important for a beginner. It's better IMHO to know how to do something right, than why something is right. This reduces the mental burden in the beginning of the learning phase. The why is something that you learn over time – or maybe you are not that interested and skip it forever, also a valid thing to do.
Overall the Rust community does a stellar job providing so much help in so many different ways – /r/rust on Reddit is really awesome – thanks for the book and your open mind to ask for feedback.
I don't think I was the only one, because in 0.31 they added the option to remove that lifetime as long as you are happy disposing of the textures yourself. If you do the following in your Cargo.toml they go away.
[dependencies.sdl2]
version = "0.31"
default-features = false
features = ["unsafe_textures"]
Maybe there is!
Some small public APIs are backed by large enough implementations that it pays off to be able to test implementation details. Sure, it might be "poorly factored" code that should have a bigger API and smaller guts, but that's not always an something you can change. Also, writing tests for internal behavior before refactoring can give you a good blueprint for how the refactored code should behave--being able to read the tests to specify unclear behavior is, while far from enjoyable in some cases, better than nothing.
You're right that there are some pretty silly test suites that break encapsulation for a coverage number without actually testing anything useful, though.
I don't think an absolute "all tests must behave thus" rule (e.g. coverage requirements, "only test public functionality", "refactor the instant something isn't easily testable") is useful. Explain the benefits of each path, and make sure the decision of what compromise to make--and in any project more than a one-developer hobby, you will have to compromise here eventually--is in the hands of people with the experience and common sense to make the right one.
But you can also throw a `#[test]` function alongside the implementation. It's sometimes super convenient to test a leaf helper function directly instead of mocking a whole program around it. And because the test lives next to the implementation, it's easy to change or delete it when the impl changes.
There's another nice side-effect of having one standard test framework - `cargo test` can test any Rust program. The Rust team can automatically test new compiler releases against all known Rust code: https://github.com/rust-lang-nursery/crater
As a random example, say you're making a data-structure of some sort, and you need to write some internal mechanism to mutate it (balancing a binary tree, resizing a hash table, whatever). If that internal mechanism is somewhat complicated, or gets called many times in public call (or even recusively), it's nice to be able to write tests for it specifically, to make sure you got this critical piece of the puzzle right.
Writing a test for just the public interface would probably catch that SOMETHING is wrong, but not what part of the code. It's basically a version of sprinkling your code with assertions to make sure you've got your invariants covered.
He then concludes that he likes things about Rust but then states Rust is a lot harder to learn but you become a better programmer cause you have to work harder on it. But isn't that what he complains about with C?
Those things have nothing to do with good or bad code and have everything to do with the language.
You're totally missing the point dude. The point is that C doesn't protect developers from some of the most basic mistakes and offers very little tooling compared to modern languages. It turns out that maintaining huge software projects in C is actually really hard.
The difference is that when you haven't learned/aren't good enough in C, you'll make a codebase that sort-of works for now but is buggy and unmaintainable - code that reads uninitialized values or never free()s or works as an application but could never be turned into a library - whereas in Rust your code won't compile until you get good enough to write it properly.
I don't want to come across as dissing rust. I've only tinkered with it and liked the parts I saw but feel some of his comments are misplaced.
EDIT: Obviously no one gets my point after twice explaining, that he's complaining about badly written code by bad programmers as his reason for dissing C, so I'll refrain from commenting anymore.
Of course people will write broken code in Java, safe Rust, Javascript. Fortunately the consequence of broken code in these languages is restricted to the application with the broken code. Broken C code threatens your entire computer.
As does broken hardware.
> To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.
-- Dennis M. Ritchie
https://www.bell-labs.com/usr/dmr/www/chist.html
Any feature that is outsourced to an external tool, has a very high probability of being ignored, and as such, yes it is a failure of the language's design.
The problem is, that at least 99% of C-programmers aren't good enough to use C. Seriously.
If you had a vehicle model that causes 99% of drivers to crash, wouldn't you say there's a problem with the vehicle rather than with the drivers?
We have now 40 years worth of proof that C is simply too difficult language to master in general case. Isn't that already enough?
I use C daily and have about 20 years of experience, but still don't consider myself to be good enough to use it. There was a time in the past when I did think I mastered it, but I was a fool back then.
This is not to say my code doesn't work; it does. It just sometimes has some weird edge cases compilers and static analysis didn't catch.
This is very bad in the era of network connected computers, because those edge cases are and will be actively exploited.
It's common to hear this line from the C fandom, and very rare to hear a serious proposal for what to do with all this Bad Code written by Bad Programmers. The status quo is to rewrite the former from scratch, and totally ignore the latter in the hopes that they'll be magically pulled down to hell and have their hands burned off by daemons. As far as I know, that part doesn't actually happen. Instead, they just keep writing more Bad Code, and meanwhile the rewrites are just as liable to cause problems as whatever they replaced, because often as not, the people doing the rewrites also turn out to be Bad Programmers.
If pressed for actionable solutions, C advocates will sometimes mention tooling such as Valgrind and ASAN, as if merely having it exist guarantees that all C programmers are educated in its use and make it a part of their workflow. This clearly isn't the case. New programmers are still learning C from material written before such tooling existed. Old programmers are still recommending it. There's no path for Bad Programmers to become Good Programmers, except to be admonished in public to Stop Writing Bad Code.
Ultimately, I agree with you: The issue here isn't with the C language. It's with the people who use it. Their priorities do not include concerns like memory safety, and their normal response to questions of code quality is to make it somebody else's problem.
If the culture of the community were to change, I expect the language would follow.
Actually we do. We're just not indulging your point. It's the same point that has plagued every new tool and technique that has ever emerged; "we don't need this, the exiting tools are fine, just be a better programmer." "See? If you just program better you wouldn't need this pointless such and such." I suspect this mentality is found in every field of endeavour.
The world you envision, where world class programmers write and maintain flawless code and everyone else stays home, is fictional. It has never been and it will never be. Thus we pursue tools to improve the state of the art despite the lack of exclusively world class programmers.
Maybe Rust is one of the right answers. Maybe not. I don't know. I just know that most of us are straight up done putting up with people that insist the pursuit of better tools is somehow misguided. Figure that out and you'll do better.
Not significantly, not as long as they are C compilers and thus accept all valid C code.
Yes, without -Werror, C compilers won't act on diagnostic warnings. But C compilers can and do warn about "valid C code" that happens to set off alarm bells.
And with -Werror, they reject some valid C code.
Now you can ask for lots of warnings, -wall, but I suspect many people turn that off after the first ASCII tsunami.
And even those two doesn't get you everything. Clang's got -Weverything, but the developers suggest it's an internal feature and shouldn't be used. From there you have to manually identify and add -Wfoo options.
When I write my own code I turn on as many compiler warnings as I can, and make sure it compiles clean. If there were more warnings I'd turn them on.
Problem is usually third party libraries. Plenty of open source projects don't give a single shit about compiler warnings and unsafe practices. So if I include a header from libSomething package, here come 10k warnings. I remember one project (don't remember which one) specifically said in its documentation something like "don't submit patches to fix compiler warnings, it's impossible to keep up with every complaining compiler out there." With programmers like that out there, what hope do we have?
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wfoo"
#include <my_3rd_party_header.h>
#pragma GCC diagnostic pop
(Despite the "GCC" moniker, Clang supports the same approach.)
Rust's innovation here is that it can separate these cases based on lifetime annotations on functions and types, where the program text itself disambiguates its intentions.
So to get much closer than current -Wall -Wextra, you need to either impose some default assumptions (the C++ core guidelines do this) or start adding annotations somehow.
Unless you're using caret requirements, or tilde requirements, or wildcard requirements, or inequality requirements, or multiple version requirements, or dependency overrides.
By default, Rust, much like every other language I know of, does not require explicit versions or checksums for dependencies. This means it's up to the developer to work really hard to make sure their code will actually work as expected outside of their own build environment. This could be mostly avoided if more people used explicit version requirements in their code, but nobody seems to want to do this (which is strange, because your code is what needs specific deps, so why not keep the version requirements right there?)
edit: For all the duplicate comments mentioning cargo.lock: The official FAQ details how libraries do not impose requirements at build time (https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-hav...): "Users dependent on the library will not inspect the library’s Cargo.lock (even if it exists)". The user cannot be certain their app will always work, because they can't be certain that their dependent library has been tested on each other library dependency. Basically, there's no certainty if you use libraries.
The other thing people are missing is how being able to call duplicate conflicting versions of the same library where it is needed in your code would allow you to work around complicated bugs in large projects automatically, rather than having to find a magic combination of conflicting dep versions that work for your app and its dependencies. Apparently nobody here has ever tried to manage more than one OpenStack tools tree for use by the same application.
Of course, Cargo.lock will keep your dependencies locked exactly until you decide you want to upgrade.
Cargo already does this automatically if two of your dependencies depend on conflicting versions of the same library.
And for what it's worth, the libraries on crates.io seem to follow semver closely enough that the problem you describe doesn't really come up.
> > call duplicate conflicting versions of the same library where it is needed in your code
>
> Cargo already does this automatically if two of your dependencies depend on conflicting versions of the same library.
For example, let's say my project depends on two libraries; A and B. Both depend on library C.
If A depends on C version ^ 1.0.0, and B depends on C version ^ 1.1.0, and 1.2.0 is the latest version of C, then both A and B will end up with C 1.2.0.
If A depends on C = 1.0.0, and B depends on C version = 1.1.0, then you'll get two copies of C.
B is expecting C = 2.0.0. A is expecting C = 1.0.0. A makes a call to B, which it passes to C. Does A know that B now expects to be called differently, since C is also significantly different now? According to the above requirements, no version of the deps exist that could allow the app to execute correctly, even though it will technically build fine.
The way to resolve this would be to say A requires C < 2.0.0, and simply fail to build until someone fixes A. But you probably won't even know about this conflict until someone tests the app with a specific feature of A that conflicts with C >= 2.0.0, the build fails, someone figures out the conflict, and updates the requirements.
But you can only know this, and add this requirement, once you have found the conflict. Thus code in the present, even with dependency requirements, may be indeterminate in the future. (Unless you walk back through all calls in the code to find calls between multiple dependencies that eventually land on conflicts... but I don't think that is possible in Turing-complete languages)
If you pinned the version in each function call in each part of the code, you could have the compiler or interpreter walk back through dependent code, identify mismatches, retrieve a compatible dependency, and continue execution. Or at the very least throw warnings all over the place when code is running using dependencies it wasn't written for.
Funny enough, what you describe is theoretically possible in JavaScript, but strangely enough, it seems to work... it's something I've long been trying to come up with a POC exploit for.