You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Global allocator to use heap memory in no-std environment#[global_allocator]staticALLOC:BumpAlloc = miden_sdk::BumpAlloc::new();// Required for no-std crates#[panic_handler]fnmy_panic(_info:&core::panic::PanicInfo) -> ! {loop{}}
The macro could be called miden_setup. My only concern is that we might be insulating the developer too much from being in the no_std land.
The other thing, is that they are not intended to be written by the developer and provided in the new project template. So we're not helping the developer to write them but hiding them for the optics.
The text was updated successfully, but these errors were encountered:
I think if we document the macro well enough, it should be fine.
Quick question: what does setting panic handler to an infinite loop actually do? (I'm assuming it does not result in infinite loops on panic). Maybe worth documenting this.
Quick question: what does setting panic handler to an infinite loop actually do? (I'm assuming it does not result in infinite loops on panic). Maybe worth documenting this.
#[panic_handler] is used to define the behavior of panic! in #![no_std] environment. It should have the following signature fn my_panic(_info: &core::panic::PanicInfo) -> ! so it should never return (! is never type). In the no_std environment, there is no operating system to return to, so I suppose the looping forever is the only thing that goes nowhere else in the program in a platform independent way. In Wasm, there is unreachable instruction that is a trap, so
is more appropriate for Wasm targets since it compiles to its unreachable instruction. However, it is not that much of a difference in our case since we're re-building core, alloc libraries with effectively ripped out panic infrastructure (see)
In the new project template:
in
https://github.com/0xPolygonMiden/rust-templates/blob/3aa6c9dc5fceb8fc0975270c12b98267e3abbde6/account/template/src/lib.rs#L10-L19
The macro could be called
miden_setup
. My only concern is that we might be insulating the developer too much from being in theno_std
land.The other thing, is that they are not intended to be written by the developer and provided in the new project template. So we're not helping the developer to write them but hiding them for the optics.
The text was updated successfully, but these errors were encountered: