Re:size_t-to-int vulnerability in Linux’s filesystem layer
by eloff on Tuesday July 20, 2021 @01:30PM
(#27896642)
I would prefer not to see that happen, I'm fine with as and the safer options as they are currently. It would be a big job to update all the code in the wild when you want to move to the newer edition.
[ Parent
| on HN ]
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by tialaramex on Tuesday July 20, 2021 @01:45PM
(#27896816)
I don't see it as a big job. Am I wrong?
Imagine there's a suitable narrow::<type>() function introduced which has the same consequence, always narrowing, if your data was too wide it may drop important stuff on the floor, and narrow() just says that's too bad.
Rust 2030 can introduce narrow::<type>(), warn for narrowing as usage and then Rust 2035 can error for as. The Rust 2030 -> 2035 conversion software can consume code that does { x as y } and write { x.narrow::<y>() } instead. This code is not better but it's still working in Rust 2035 and this explicit narrow() function is less tempting for new programmers than as IMO.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by scns on Tuesday July 20, 2021 @04:29PM
(#27898871)
Yes, BUT the correct thing to do would be more tedious to write that way.
Re:size_t-to-int vulnerability in Linux’s filesystem layer
by wizzwizz4 on Tuesday July 20, 2021 @01:41PM
(#27896755)
You don't need to do that. Rust editions are fully backwards-compatible, since they can depend on code from different editions.