Should there be informational advisories against old versions of crates that construct uninitialized integers? #1194
Description
The standard library has a stern warning against use of mem::uninitialized that it sort of walks back at the end:
Worse, truly uninitialized memory like what gets returned here is special in that the compiler knows that it does not have a fixed value. This makes it undefined behavior to have uninitialized data in a variable even if that variable has an integer type. (Notice that the rules around uninitialized integers are not finalized yet, but until they are, it is advisable to avoid them.)
There has been a slow but very broad ecosystem move away from this function. For example, itoa published a 1.0 release 2 months ago which removes use of this function. bytes used to use it too, as well as crossbeam. I've run cargo audit on crates that depend on versions of these crates which call mem::uninitialized and I don't come up with anything for itoa, bytes, or crossbeam. I've selected these crates specifically to call out, because I know they construct uninit instances of u8 or usize and I know that pre-patch versions of them are in use.
I think it would be fair to indicate to users that they should upgrade, given how long it's been since a patch and that itoa changed basically not at all with 1.0. But does "constructs uninit integers" meet the bar for a RustSec advisory in light of the fact that it's definitely a bad idea, but unclear if it's UB? It's unclear to my mind if this is the same kind of thing as assuming the layout of SocketAddr.