Use unsafeWithForeignPtr in Data.ByteString.Unsafe

[Bodigrim]

As pointed out by @bgamari at https://gitlab.haskell.org/ghc/ghc/-/snippets/2920 and https://gitlab.haskell.org/ghc/ghc/-/issues/19557#note_357737

[sjakobi]

These instances do seem good to convert to the unsafe version. There's still a bunch of withForeignPtrs in the library though, e.g. in BS.split. Did you or @bgamari make a complete pass over these?

In functions like findIndex and filter, I suspect we have to stick with withForeignPtr because the user-defined predicates can't be assumed to be safe?!

[Bodigrim]

As far as I understand from https://gitlab.haskell.org/ghc/homepage/-/merge_requests/84/diffs, since unsafeWithForeignPtr is equivalent to pre-9.0 withForeignPtr, and bytestring was doing just fine with the latter, we can make all instances unsafe.

@bgamari in b82da95 does not hesitate to use unsafe version even for functions with callbacks such as foldl'. It is dangerous to use unsafe, if a callback can be divergent, but useful at the same time (e. g., does something in IO, like forever $ ...). But if a callback is a pure function, throwing error, it probably does not make much difference to touch or not to touch. @bgamari any chance to chime in and clarify our understanding, please?

[bgamari]

@bgamari in b82da95 does not hesitate to use unsafe version even for functions with callbacks such as foldl'. It is dangerous to use unsafe, if a callback can be divergent, but useful at the same time (e. g., does something in IO, like forever $ ...). But if a callback is a pure function, throwing error, it probably does not make much difference to touch or not to touch. @bgamari any chance to chime in and clarify our understanding, please?

Sure. Let's look at the case of foldl':

foldl' :: (a -> Word8 -> a) -> a -> ByteString -> a
foldl' f v (BS fp len) =
    accursedUnutterablePerformIO $ unsafeWithForeignPtr fp g
  where
    g ptr = go v ptr
      where
        end  = ptr `plusPtr` len
        -- tail recursive; traverses array left to right
        go !z !p | p == end  = return z
                 | otherwise = do x <- peek p
        go (f z x) (p `plusPtr` 1)

Note how go does work (namely predicating on p == end) before applying the user-supplied f. Consequently, it is impossible for GHC to conclude that go unconditionally diverges, even if f does.

In general, the question to ask yourself in these situations is:

can the user provide inputs to the function that would cause it to diverge unconditionally.

[Bodigrim]

@bgamari thanks, now it is much clearer.
@sjakobi I checked other encounters of withForeignPtr and pushed a patch, please take a look.

[sjakobi]

One small suggestion. LGTM apart from that.