There are several places in the example code that call MaybeUninit::uninit().assume_init(), which is undefined behavior.
Newer toolchains (e.g. rust 1.87.0) print a big warning when this code is compiled:
warning: the type `XSetWindowAttributes` does not permit being left uninitialized
--> src/main.rs:25:58
|
25 | let mut attributes: xlib::XSetWindowAttributes = mem::MaybeUninit::uninit().assume_init();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| this code causes undefined behavior when executed
| help: use `MaybeUninit<T>` instead, and only call `assume_init` after initialization is done
|
= note: integers must be initialized
= note: `#[warn(invalid_value)]` on by default
Values must be initialized before being accessed; MaybeUninit does not excuse the code from that requirement.
There are several places in the example code that call
MaybeUninit::uninit().assume_init(), which is undefined behavior.Newer toolchains (e.g. rust 1.87.0) print a big warning when this code is compiled:
Values must be initialized before being accessed;
MaybeUninitdoes not excuse the code from that requirement.