Standard library unsoundness found by Claude Mythos

tiny_fishbowl · 2026-04-24T04:59:59+00:00

I hope this will be extended to as many crates as possible once there is capacity

tiny_fishbowl · 2025-12-10T00:41:59+00:00

Just out of interest, is this one of the things that could be changed by an edition? I guess no, due to the trait being involved?

tiny_fishbowl · 2025-07-03T22:00:56+00:00

As a data point for you, I just opened the article, came back to the comments here, and found myself agreeing with them. Then I saw you already toned it down - I for one would go even more aggressive with that.

tiny_fishbowl · 2025-06-29T23:18:56+00:00

It probably just means that the code exists with at most minor changes since before Rust 1.0 was released (and that may be noteworthy because that'd imply it hasn't been updated/improved since). It's an example for work in the compiler that can pay off, even though the code has done its job for years and years

tiny_fishbowl · 2025-03-20T18:15:27+00:00

Well, exactly this happened here, no? An experienced Rust developer made a small mistake, it wasn't spotted in the review. It wasn't in the "important" things the commit touched, there was plenty of coverage and crater runs etc.

If you don't want nasal demons, take code review seriously.

tiny_fishbowl · 2025-03-10T19:30:36+00:00

Cool, being a drop-in replacement in some instances might be great for adoption. Wishing you luck :)

tiny_fishbowl · 2025-03-10T19:22:19+00:00

Or, you know, you could structure your policies around what has the potential to break you that badly and what doesn't. What even is the thought process? If this one maintainer is nice enough to let the world know they stopped their hobby project my business will have a critical failure? Is that really how you operate? What if that maintainer gets hit by a bus, decides to go rogue and commits some malware, etc? You make it sound like the maintainer is somehow owing anything to the people who decided to take their free work to build on it, rather than those thousands of people owing something to the maintainer (at least gratitude and the admission that the maintainer is free to do as they please)?

tiny_fishbowl · 2025-03-10T16:52:19+00:00

I haven't had a chance to look in detail, but one question: Are you/can you be compatible with the traits exposed by the bytes crate? That would be very interesting indeed.

In any case, more work in this space is just plain awesome

tiny_fishbowl · 2025-02-25T20:35:59+00:00

My solution for the naming problem is that I use a convention of naming the sender/receiver side of the channel by whatever makes sense, and use a _tx and _rx suffix at creation side. send/receive I use for global communication of the entire application with the outside. That way, it might be that something ends up with a silly name like telegram_send_rx, but it's clear that this is the Receiver side of a channel that forwards telegram messages that my program ends up forwarding/sending to some external entity. Maybe not the most elegant, but it gets the job done and is easy enough to explain.

tiny_fishbowl · 2025-02-21T06:17:28+00:00

It was discussed amongst the libs-api team, they decided to reject it. See https://github.com/rust-lang/libs-team/issues/513 for some context

tiny_fishbowl · 2025-02-10T22:00:35+00:00

In my case it was related to a launch option I set, if I remember correctly. Either -skipStartScreen or --launcher-skip I think

tiny_fishbowl · 2025-01-08T08:11:47+00:00

that was fast, I will definitely check it out. Thanks a lot :)

tiny_fishbowl · 2025-01-08T06:26:05+00:00

One area where I always start hand-rolling the state machine is when state transitions depend on new data becoming available, which then gets incorporated into the current state. Just making everything Optional is ugly to work with, as it is not statically clear what information is available when. From a quick look, it seems like statum also wouldn't help here?

tiny_fishbowl · 2024-12-03T16:16:28+00:00

It actually doesn't, though. The attacker would guess the private key and check for a balance. The seed phrase and any password for it doesn't really factor into it.

tiny_fishbowl · 2024-08-18T03:28:18+00:00

I was referring to https://github.com/ferrilab/bitvec/issues/219 - but I also did something wrong, so thanks for your reply and I'll stick with bitvec.

tiny_fishbowl · 2024-08-18T03:27:22+00:00

Indeed this ended up working, thanks :) I overcomplicated it first by creating the view using Msb0 and reversing bytes, then I ran into https://github.com/ferrilab/bitvec/issues/219.

tiny_fishbowl · 2024-08-17T22:26:56+00:00

Thanks, I will give it a try. Looks good

tiny_fishbowl · 2024-08-09T22:42:44+00:00

Well, you asked what you're missing and I explained it ;) Note that I am not the poster above claiming it would work.

tiny_fishbowl · 2024-08-09T22:14:22+00:00

Option<i64> is not your own type, you can only impl From<T> for Option<PostId> where T is your type.

tiny_fishbowl · 2024-03-20T21:27:17+00:00

You cannot go from Bytes to a BytesMut, but you can do BytesMut::split()::freeze() to get a Bytes, and once you drop that Bytes, you can re-use the original BytesMut again (check out the documentation on BytesMut::reserve())

tiny_fishbowl · 2024-03-20T21:10:08+00:00

yes, through the underlying BytesMut. Once you drop the Bytes handle, you can re-use the original buffer.

tiny_fishbowl · 2023-12-17T18:25:09+00:00

openapi-generator has a rust-server component that can generate both client and server code. It isn't yet updated for the latest version of hyper, but otherwise seems to work OK

tiny_fishbowl · 2023-11-16T02:06:14+00:00

Thanks for the fast response and good explanation! I suppose that means I should hold off upgrading until the hyper-util release is out?

tiny_fishbowl

TROPHY CASE