Does Haskell have any similar line? What is the property that code must have in order for it to be a bug to segfault? Must not call `unsafePerformIO`? Must not call `unsafeCoerce`? (Must not call any function with the `unsafe` prefix?)
In other words, is the segfault here to be considered a bug in the language -- or is unwrapping IO one of the things that, if you do it, you're own your own and may segfault? (Is part of the point of the article is that it is currently considered safe but should not be? Is that a bug in the language or in peoples' expectations?)
Or is a clear line like this not a notion that Haskell has? It's been a long time since I've done any Haskell, though I don't recall any clear guideline like this!
unfortunately this is as far as that goes
Teeechnically, it's not true. Unfortunately, you can trigger a memory error in safe code by overflowing stack by allocating big objects on stack, executing poorly written recursive code, or spawning a thread with small stack. In older Rust versions you literally got segfault in such cases.
It's just not something you do, I don't think there is any specific reason to do that. And article itself says
> Using this constructor directly can be unsafe
accursedUnutterablePerformIO
> The tricky bit is that this line is not enforced by syntax or by the type system (unlike Rust, where you have a syntactic label `unsafe`).
To be able to do it in the first place, I think you need to import libraries that expose compiler internals, so I would say it belongs in the "you're on your own" category, yes.
Also if you try to Google how to do it, every hit says "don't do it".
> Contrary to popular belief, unwrapping the IO constructor is deeply unsafe and can violate memory safety, even if State# tokens are never duplicated or dropped.
Does ANYONE believe that unwrapping the IO constructor is normal and safe? I must live in a very sheltered bubble. Isn't it extremely obvious that once you get that state function out of the IO constructor, you can build your own unsafePerformIO?
nssnsjsjsjs•8mo ago