This would be a feature-test cfg, similar to target_has_atomic.
It would test for if the platform has an OS that cleans up a process's resources after it exits.
It would be true on high level hosted platforms like linux, windows, and redox.
It would be false on embedded platforms and those without strong isolation, such as uefi and bare metal targets.
The purpose of this cfg is for applications with large heap datastructure which want to be able to exit quickly. They can use this cfg to robustly test if they can just leak this memory before exiting and rely on the OS to clean it up like an arena allocator.
1 Like
I'm not familiar with UEFI so maybe things are different there, but on typical bare metal embedded platforms there is no such thing as a process to begin with and no such thing as a process exiting; returning from main is usually either going to just stop the device forever (by going into an infinite loop/sleep/whatever) or is going to end up effectively rebooting it, and in those cases there is also no need to clean up heap allocations/etc before "exiting".
What's an example of an environment where it is mandatory to free memory before "exit"?
1 Like
uh.. UEFI? that's the main one that's supported in the standard library now, but it would be nice to have it for future proofing. lots of embedded OSes have a concept of independently scheduled processes, but don't have memory isolation.
If your "processes" share the same heap allocator then I'd call them threads, but the ship long since sailed on a consistent definition of those terms anyway 
I was mostly just curious, but I guess my point is that if there was a config for "there is no need to worry about freeing stuff before exit" then I would expect it to be true for bare metal environments and would find it pretty surprising that a program built using little more than cortex-m-rt claims that it needs to free stuff before exiting.
Does the UEFI target also prevent you from using panic="abort"?