Re: opt out of accursedUnutterablePerformIO

Am 04.03.2018 um 15:58 schrieb Ben Gamari:

On March 4, 2018 5:19:26 AM EST, Ben Franksen wrote:

...

I had a program I was working on lately (darcs) crash with a segmentation fault after I made a seemingly harmless refactoring. [...]>> So I looked at the bytestring library to see if there was something that could explain the crash. I found that it uses accursedUnutterablePerformIO all over the place.

The dire warnings accompanying this "function" (including the citation of a number of problem reports against commonly used libraries) made me think that it may be worthwhile to offer an opt-out for users of libraries like bytestring or text. (Note that I am not claiming my particular crash is due to a bug in bytestring, I merely want to exclude the possibility.)

For the libraries in question it would be simple to do this: just add a cabal flag to optionally disable use of accursedUnutterablePerformIO.

That still leaves the question of how users can make their project depend on a bytestring that has been built with this flag. I know this can be done with manual installation of a new version of the library, but I would rather use cabal new-build (as I am used to) and let it figure out itself that it has to attach a new hash to the variant with the flag.

I'm afraid it's not possible to provide the interfaces exposed by bytestring without some form of unsafety. Lazy IO alone requires unsafeInterleaveIO and the bytestring indexing operations require at very least unsafePerformIO since GHC treats access to foreign memory as an effect.

I am well aware of that.

accursedUnutterablePerformIO is an optimized form of unsafePerformIO which likely won't cause any issues that wouldn't otherwise manifest with plain unsafePerformIO. Consequently I am not sure it's worth providing a means to disable its usage.

I envy your confidence. The documentation mentions two bytestring commits that fix bugs by reverting accursedUnutterablePerformIO to unsafePerformIO. I guess this is plain evidence that there can in fact be "issues that wouldn't otherwise manifest with plain unsafePerformIO". Anyway. Would you perchance have any idea what could possibly make a program work fine with the first version of linesPS and crash with the second one? I find this pretty scary and would like to understand it. Cheers Ben