ceteia
https://github.com/thelowsunoverthemoon/mahler.c/blob/4ebfe8...
Should that type have been mah_acci instead of int? mah_acci doesn't seem to be used anywhere.
Also, have you considered using (edit) designated initializer syntax for some of the function calls that take in structs as arguments?
https://cppreference.com/w/c/language/struct_initialization....
struct mah_scale scale = mah_get_scale(
(struct mah_note) {
.tone=MAH_C,
.acci=MAH_NATURAL,
.pitch=4
},
&MAH_BLUES_SCALE, notes,
MAH_ASCEND,
NULL
);How old are you? I assume that you are at least 30 years old, possibly 40 or more years old.
> That is, all (or at least, all of it that I could find) was wrapping an unsafe API with documented (and usually straightforward and local) invariants that maintain safety, such that the calling code is safe.
A comment does not automatically make code safe. What even is that argument? There have directly been examples of Rust code with SAFETY comments that later were found to be memory unsafe.
This is not always true, as seen with rustc 1.80 and the time crate. While it only changed type inference, that still caused some projects like Nix a lot of trouble.
And you are not being honest nor accurate here.
However, I can at least give you a hint: If you have a block of unsafe, is it sufficient to inspect that block of unsafe code if a change is made to a different part of the code that is not in an unsafe block if one is seeking to avoid memory unsafety? If he has done his basic homework, he should have known the answer to that and the consequences of it.
You can also consider this: Why do some Rust projects which do not contain a single line of unsafe, still run Miri, a tool that is designed to catch some (not all) undefined behavior and memory unsafety, and which can run 50x-200x slower than regular Rust? An example can be seen in https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ , where the author used Miri to find memory unsafety in a dependency, upstreamed a fix to that dependency, and then encountered memory unsafety in a different dependency and gave up.
> If you use a crate in your Rust program, Miri will also panic if that crate has some UB. This sucks because there’s no way to configure it to skip over the crate, so you either have to fork and patch the UB yourself, or raise an issue with the authors of the crates and hopefully they fix it.
> This happened to me once on another project and I waited a day for it to get fixed, then when it was finally fixed I immediately ran into another source of UB from another crate and gave up.
https://grep.app/search?f.repo=servo%2Fservo&f.repo.pattern=...
So Servo at the very least cannot be said to be 'safe'. And I believe the Rust code in Firefox is similar.
Your lucky soul analogy argument doesn't make any sense.
And then there was https://en.wikipedia.org/wiki/Ariane_flight_V88 , where US$370 million was lost. The code was written in Ada.
And using seat belts and wearing helmets do not help in those cases where 'unsafe' is used to take the seat belts and helmets off. And that is needed in Rust in a number of types of cases, such as some types of performance-sensitive code.
https://github.com/trifectatechfoundation/sudo-rs
https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo...
And Miri is very popular in Rust. Even if a Rust project doesn't have unsafe, sometimes people still run Miri with it, since dependencies might have messed up their unsafe usage.
Chromium is filled with sloppy and old code. Some of the source code (at least if dependencies are included) is more than 20 years old, and a lot of focus has been on performance, not security.
Using Rust does not necessarily solve this. First, performance-sensitive code can require 'unsafe', and unsafe allows for memory unsafety, thus going back to square one, or further back. And second, memory safety isn't the only source of vulnerabilities. Rust's tagged unions and pattern matching help a lot with general program correctness, however, and C++ is lagging behind there.
Edit: Replying to ghusbands:
'unsafe' is a core part of Rust itself, not a separate language. And it occurs often in some types of Rust projects or their dependencies. For instance, to avoid bounds checking and not rely on compiler optimizations, some Rust projects use vec::get_unchecked, which is unsafe. One occurrence in code is here:
https://grep.app/pola-rs/polars/main/crates/polars-io/src/cs...
And there are other reasons than performance to use unsafe, like FFI.
Edit2: ghusbands had a different reply when I wrote the above reply, but edited it since.
Edit3: Ycombinator prevents posting relatively many new comments in a short time span. And ghusbands is also wrong about his answer not being edited without him making that clear.
https://materialize.com/blog/rust-concurrency-bug-unbounded-...
match (0, 1, 2) {
case (F(), 0, G()) => ...
}
How would that work with exhaustiveness checking? As far as I can tell, they themselves believe that Carbon's exhaustiveness checking will be very poor.
And OK with implicit conversions? Especially when combined with their way of handling templates for pattern matching?
GitHub's survey did not say much about Rust I think, despite Rust projects often having lots of starring. Rust projects might have a greater ratio of stars-to-popularity than projects in other languages, though.
StackOverflow's survey was much more optimistic or indicated popularity for Rust.
Redmonk places Rust at place 19th.
In case that you are well familiar with for instance pattern matching, might you have any opinions on the pattern matching that is currently proposed for Carbon?
https://docs.carbon-lang.dev/docs/design/pattern_matching.ht...
But that is not what the claim is about, it is about any new driver, not a specific one.