oconnor663

8 ms·

91.
by oconnor663 1y ago
Sure but of those 99%, how many are performance-sensitive, CPU-bound (in Python not in C) applications? It's clearly some, not saying it's an easy tradeoff, but I assume the large majority of Python programs out there won't n
92.
by oconnor663 1y ago
I think this is conflating two different things. A Rust Mutex gets poisoned if the thread holding it panics , but that's not the same thing as evaporating into thin air. Destructors run while a panic unwinds (indeed this is how the Mu
93.
by oconnor663 1y ago
> Could owner be something else than a stack frame? Yes. There are lots of ways an object might be owned: - a local variable on the stack - a field of a struct or a tuple (which might itself be owned on the stack, or nested in yet anothe
94.
by oconnor663 1y ago
This account's been pretending to be Matt Godbolt since 2014. Knows him better than he knows himself. Absolute commitment to the bit.
95.
by oconnor663 1y ago
> The borrow checker rejects loads of sound programs - just read https://rust-unofficial.github.io/too-many-lists/ It's important to be careful here: a lot (most? all?) of these rejections are programs that cou
96.
by oconnor663 1y ago
Can you give some examples of Rust features that you don't need? Unfortunately a lot of common answers (the borrow checker, traits, move semantics) are things that are fundamental to the safety story. I guess one thing you could defini
97.
From Rust to C and Back Again: an introduction to "foreign functions" [video](youtube.com)
2 points by oconnor663 1y ago|0 comments
98.
by oconnor663 1y ago
If we know each other's DH public key in advance, then you're totally right, DH is secure over an untrusted network. But if we don't know each other's public keys, we have to get them over that same network, and DH can&#
99.
by oconnor663 1y ago
> There's a problem to be solved "valid"
100.
by oconnor663 1y ago
They MITM the key exchange step at the beginning, and now they do have the keys. The thing that prevents this in TLS is the chain of signatures asserting identity.
101.
by oconnor663 1y ago
> It has very few opinions about your code I understand where this is coming from, but I think this is less true than it used to be, and (for that reason) it often devolves into arguments about whether the C standard is the actual source
102.
by oconnor663 1y ago
> Predictable response: "But they can only occur in unsafe regions which you can grep for" and my response to that: "so?" The situation is both worse than this and better than this. Consider the .set_len() method on R
103.
by oconnor663 2y ago
(Rereading your comment, it sounds like you might already know all of this. Apologies.) If I understand correctly, here's a C++ example that has undefined behavior: int foo() { const int x = 42; int *p = (int *)&a
104.
Two Attacks on Naive Tree Hashes(jacko.io)
6 points by oconnor663 2y ago|0 comments
105.
by oconnor663 2y ago
If you're going down in zero visibility, what good can you do staying in the jet?
106.
by oconnor663 2y ago
C-with-sanitizers is miles ahead of what C used to be, but just a couple weeks ago I ran into a dangling pointer bug that ASan doesn't catch. (Sidenote 5 here: https://jacko.io/smart_pointers.html ) It seems like one of
107.
by oconnor663 2y ago
On top of those fundamentals, there have been more recent developments: https://doc.rust-lang.org/std/ptr/index.html#strict-provenan... https://www.ralfj.de/blog/2018/07/24/poin
108.
by oconnor663 2y ago
The way that expert programmers make these same mistakes is by introducing a few layers of abstraction. Here's a real CVE from Microsoft: https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst... &
109.
Smart Pointers Can't Solve Use-After-Free in C++(jacko.io)
5 points by oconnor663 2y ago|2 comments
110.
by oconnor663 2y ago
If you haven't been maintaining any Rust code, you might have the impression that breaking changes are far more common than they really are. Rust has about as many breaking changes as Go, probably fewer? (Because Go lacks an edition me
111.
by oconnor663 2y ago
I'm no kernel dev, but I assume that DMA bindings (what this round of drama was originally all about) fall squarely into "stuff that drivers obviously need".
112.
by oconnor663 2y ago
Granted, there are plenty of people who don't understand these issue very well who think "Rust = no bugs". Of course they're wrong. But that said, this CVE is an interesting example of just how high the bar is that Rust
113.
by oconnor663 2y ago
This is exactly the position Christoph Hellwig took in the original email chain that kicked off the current round of drama: https://lore.kernel.org/rust-for-linux/20250131075751.GA1672... . I think it's fair to say
114.
by oconnor663 2y ago
> defers are function-scoped instead of block-scoped. I think this is a basic tradeoff with defer and not a problem per se. Are users more likely to need to clean up resources every time through a loop, or more likely to acquire resource
115.
by oconnor663 2y ago
I'm not sure whether this is exactly what you mean, but when you need to support deletions you can switch to a "generational" collection like Slab or SlotMap. Your indexes are still integers, but under the covers some of the
116.
by oconnor663 2y ago
I have two different reactions to this: - From the perspective of e.g. C++, I don't think it's reinventing the heap. We often prefer to use indexes into a std::vector or similar, even when putting everything in std::shared_ptr is
117.
by oconnor663 2y ago
I don't think the indexing strategy is more straightforward in general. It's a thing you have to learn, and the fact that you have to learn it is part of Rust's famously steep learning curve. That said, there are some common
118.
by oconnor663 2y ago
I think there's an important distinction here. A systems programming language needs to have all the max speed / minimum overhead / UB-prone stuff available, but that stuff doesn't need to be the default / most conve
119.
by oconnor663 2y ago
> vs. the obvious legacy/unchecked idioms You can go crazy with legazy/unchecked/unsafe stuff if you want to in Rust. It's less convenient and more difficult than C in some ways, but 1) it's also safer and more c
120.
by oconnor663 2y ago
> There's no way for Rust to prevent you from marking an array index as free and later using it. I 2/3rds disagree with this. There are three different cases: - Plain Vec<T>. In this case you just can't remove elemen

More ›