5 ms·
What panic() Issue are you referring to? IIRC there was only a concern around allocation but the rust std is moving to fallible allocations for that reason (an
by zaarn 4y ago
What panic() Issue are you referring to?
IIRC there was only a concern around allocation but the rust std is moving to fallible allocations for that reason (and the rust integration seems to ship their own std lib anyway)
Otherwise there is no issue in redefining panic() to call the kernel oops handler and have the kernel perform a coredump.
- signa11 4y agopresumably this one: https://lkml.org/lkml/2021/4/14/1099 https://lkml.org/lkml/2021/4/14/1099 ?
- zaarn 4y agoYeah, that has become largely a non-issue, all the alloc structure allow for fallible allocation now via a separated function call (and the old ones simply use the new one with an unwrap() call to panic on error). Rust is entirely fine working with custom allocation stuff, there isn't any hidden allocator calls in you can make (well, the box operator, but that has been nightly forever and likely won't appear outside the stdlib ever).
- rascul 4y agoWhat is the box operator? This doesn't sound familiar to me, but I also don't use nightly.
- zaarn 4y agoThe box operator is basically how Box::new operates. One of the big problems if you were to DIY it, is to prevent stack allocation of heap data. The naive approach will result in your data first having to be allocated on the stack, passed to Box::new and then moved into the heap. The box operator allows moving the initialization of a datastructure into the heap entirely (and the compiler also auto-insert the malloc calls). It is largely a one-trick pony that only exists to help out the standard library, nobody should be using it ever. But it is the one instance where the rust compiler will deploy an allocation on the heap without any obvious way to tell that it did that.
- DrMeepster 4y agoBox operator isn't actually used in Box::new anymore. It's been replaced with a magic attribute, #[rustc_box]