opt out of accursedUnutterablePerformIO

[Ben Franksen]

Am 04.03.2018 um 15:58 schrieb Ben Gamari:
> On March 4, 2018 5:19:26 AM EST, Ben Franksen
> <ben.franksen at online.de> 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