Re:Violating memory safety with Haskell's value restriction
by tomsmeding on Monday May 26, 2025 @10:47AM
(#44097952)
To a certain extent, the line in Haskell is: don't use unsafePerformIO and unsafeCoerce. 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`). One generally puts "unsafe" before function names that have preconditions that are not expressed in their type, but this practice is not quite always adhered to -- though the worst offenders are reliably marked "unsafe".
Re:Violating memory safety with Haskell's value restriction
by itishappy on Monday May 26, 2025 @12:26PM
(#44098906)
There's also this classic:
accursedUnutterablePerformIO
Re:Violating memory safety with Haskell's value restriction
by thesz on Monday May 26, 2025 @01:11PM
(#44099353)
> 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`).
Re:Violating memory safety with Haskell's value restriction
by newpavlov on Monday May 26, 2025 @10:11AM
(#44097591)
>In Rust, it's considered a bug for any code which isn't using `unsafe` to encounter a memory error (e.g., to segfault)
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.
Re:Violating memory safety with Haskell's value restriction
by Rusky on Monday May 26, 2025 @02:51PM
(#44100395)
Isn't stack overflow made safe via guard pages and probes (on sufficiently high-tier target platforms)? That is you should get a guaranteed error, even if that is a segfault, and not memory corruption.
Re:Violating memory safety with Haskell's value restriction
by IsTom on Monday May 26, 2025 @10:44AM
(#44097929)
> is unwrapping IO one of the things that, if you do it, you're own your own and may segfault?
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
Re:Violating memory safety with Haskell's value restriction
by lmm on Monday May 26, 2025 @09:16AM
(#44097152)
Haskell has a definition of Safe/Unsafe/Trustworthy. I would think/hope you can't import that RealWorld type from safe code.
Re:Violating memory safety with Haskell's value restriction
by jrvieira on Monday May 26, 2025 @10:21AM
(#44097680)
https://wiki.haskell.org/Safe_Haskell
unfortunately this is as far as that goes
Re:Violating memory safety with Haskell's value restriction
by kqr on Monday May 26, 2025 @12:32PM
(#44098967)
> is unwrapping IO one of the things that, if you do it, you're own your own
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".
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!