Hacker News new | past | comments | ask | show | jobs | submit login

I'm not sure I'd consider that lib any safer than the average serialization library when things like this happen: https://github.com/serde-rs/json/issues/464



Panics are memory safe, so that’s still more safe than many parsing bugs.


The issue does not mention memory safety and neither did I. Honestly, knee-jerk reactions like "BUT MUH MEMORY SAFETY" doesn't inspire confidence specially when it couldn't help saving that dev from the troubles and bugs documented in the issue. To quote a few:

> it was a hassle to track down because Rust itself didn't complain and the panic message during serialization wouldn't tell me which file of the hundreds of thousands was causing it to die. For lack of a purpose-built tool, I had to manually bisect it until I narrowed it down.

> That said, definitely a footgun in the standard library to be remedied.

> My main concern here is getting rid of the footgun if at all possible. I really don't want to have to maintain a special "Never allow these types to creep into structs I'm deriving Serialize/Deserialize on, because the compiler certainly won't warn you" audit list.

If that's considered safe in Rust's standards then I rest my case.


Safe in rust usually has a very specific meaning: https://doc.rust-lang.org/nomicon/what-unsafe-does.html


Memory safety issues plague parsers, and often have dire consequences. rust claims to be memory safe. This bug does not invoke memory unsafety.

Yes, things can still be improved, but this is nowhere near as bad as many parsing bugs.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: