开源软件名称（OpenSource Name）：

开源软件地址(OpenSource Url)：

开源编程语言(OpenSource Language)：

开源软件介绍(OpenSource Introduction)：

Haskell's Dangerous Functions

What does dangerous mean?

Dangerous could mean either of these:

• Partial: can throw exceptions in pure code
• Unsafe: can cause segfaults
• Has unexpected performance characteristics
• Doesn't do what you want
• Doesn't do what you think it does

How to forbid these dangerous functions in your codebase

1. Copy the hlint.yaml file in this repository to .hlint.yaml within your repository

   cat /path/to/haskell-dangerous-functions >> /path/to/your/project/.hlint.yaml
   

2. Run hlint on your code. Make sure to require new changes to be hlint-clean. You can use hlint --default to generate a settings file ignoring all the hints currently outstanding. You can use pre-commit hooks to forbid committing non-hlint-clean changes.

3. Whenever you want to make an exception, and use a forbidden function anyway, use the ignore key to add an exception to the .hlint.yaml file.

FAQ

• It seems pretty silly that these functions still exist, and their dangers not well-documented.

  I know! See the relevant discussion on the GHC issue tracker.

• Surely everyone knows about these?

  Maybe, but I certainly didn't, until they caused real production issues.

Contributing

WANTED: Evidence of the danger in these functions. If you can showcase a public incident with real-world consequences that happened because of one of these functions, I would love to refer to it in this document!

If you know about another dangerous function that should be avoided, feel free to submit a PR! Please include:

• an hlint config to forbid the function in hlint.yaml.
• a section in this document with:
  • Why the function is dangerous
  • A reproducible way of showing that it is dangerous.
  • An alternative to the dangerous function

It might be that the function you have in mind is not dangerous but still weird. In that case you can add it to the Haskell WAT list.

Overview of the dangerous functions

forkIO

TL;DR: Using forkIO is VERY hard to get right, use the async library instead.

The main issue is that when threads spawned using forkIO throw an exception, this exception is not rethrown in the thread that spawned that thread.

As an example, suppose we forkIO a server and something goes wrong. The main thread will not notice that anything went wrong. The only indication that an exception was thrown will be that something is printed on stderr.

$ cat test.hs
#!/usr/bin/env stack
-- stack --resolver lts-15.15 script
{-# LANGUAGE NumericUnderscores #-}
import Control.Concurrent
main :: IO ()
main = do
  putStrLn "Starting our 'server'."
  forkIO $ do
    putStrLn "Serving..."
    threadDelay 1_000_000
    putStrLn "Oh no, about to crash!"
    threadDelay 1_000_000
    putStrLn "Aaaargh"
    undefined
  threadDelay 5_000_000
  putStrLn "Still running, eventhough we crashed"
  threadDelay 5_000_000
  putStrLn "Ok that's enough of that, stopping here."

Which outputs:

$ ./test.hs
Starting our 'server'.
Serving...
Oh no, about to crash!
Aaaargh
test.hs: Prelude.undefined
CallStack (from HasCallStack):
  error, called at libraries/base/GHC/Err.hs:80:14 in base:GHC.Err
  undefined, called at /home/syd/test/test.hs:17:5 in main:Main
Still running, eventhough we crashed
Ok that's enough of that, stopping here.

Instead, we can use concurrently_ from the async package:

$ cat test.hs
-- stack --resolver lts-15.15 script

{-# LANGUAGE NumericUnderscores #-}

import Control.Concurrent
import Control.Concurrent.Async

main :: IO ()
main = do
  putStrLn "Starting our 'server'."
  let runServer = do
        putStrLn "Serving..."
        threadDelay 1_000_000
        putStrLn "Oh no, about to crash!"
        threadDelay 1_000_000
        putStrLn "Aaaargh"
        undefined
  let mainThread = do
        threadDelay 5_000_000
        putStrLn "Still running, eventhough we crashed"
        threadDelay 5_000_000
        putStrLn "Ok that's enough of that, stopping here."
  concurrently_ runServer mainThread

to output:

$ ./test.hs
Starting our 'server'.
Serving...
Oh no, about to crash!
Aaaargh
test.hs: Prelude.undefined
CallStack (from HasCallStack):
  error, called at libraries/base/GHC/Err.hs:80:14 in base:GHC.Err
  undefined, called at /home/syd/test.hs:18:9 in main:Main

See also:

• informatikr/hedis#165
• hreinhardt/amqp#96

forkProcess

Mostly impossible to get right. You probably want to be using the async library instead.

If you think "I know what I'm doing" then you're probably still wrong. Rethink what you're doing entirely.

See also https://www.reddit.com/r/haskell/comments/jsap9r/how_dangerous_is_forkprocess/

Partial functions

head

Throws an exception in pure code when the input is an empty list.

Prelude> head []
*** Exception: Prelude.head: empty list

Use listToMaybe instead.

Applies to Data.Text.head as well

tail

Throws an exception in pure code when the input is an empty list.

Prelude> tail []
*** Exception: Prelude.tail: empty list

Use a case-match instead.

Applies to Data.Text.tail as well

init

Throws an exception in pure code when the input is an empty list.

Prelude> init []
*** Exception: Prelude.init: empty list

Use a case-match on the reverse of the list instead, but keep in mind that it uses linear time in the length of the list. Use a different data structure if that is an issue for you.

Applies to Data.Text.init as well

last

Throws an exception in pure code when the input is an empty list.

Prelude> last []
*** Exception: Prelude.last: empty list

Use a listToMaybe . reverse instead, but keep in mind that it uses linear time in the length of the list. Use a different data structure if that is an issue for you.

Applies to Data.Text.last as well

'!!'

Throws an exception in pure code when the index is out of bounds.

Prelude> [1, 2, 3] !! 3
*** Exception: Prelude.!!: index too large

It also allows negative indices, for which it also throws.

Prelude> [1,2,3] !! (-1)
*** Exception: Prelude.!!: negative index

The right way to index is to not use a list, because list indexing takes O(n) time, even if you find a safe way to do it. If you really need to deal with list indexing (you don't), then you can use a combination of take and drop.

fromJust

Throws an exception in pure code when the input is Nothing.

Prelude Data.Maybe> fromJust Nothing
*** Exception: Maybe.fromJust: Nothing
CallStack (from HasCallStack):
  error, called at libraries/base/Data/Maybe.hs:148:21 in base:Data.Maybe
  fromJust, called at <interactive>:11:1 in interactive:Ghci1

Use a case-match instead.

read

There are multiple reasons not to use read. The most obvious one is that it is partial. It throws an exception in pure code whenever the input cannot be parsed (and doesn't even give a helpful parse error):

Prelude> read "a" :: Int
*** Exception: Prelude.read: no parse

You can use readMaybe to get around this issue, HOWEVER:

The second reason not to use read is that it operates on String.

read :: Read a => String -> a

If you are doing any parsing, you should be using a more appropriate data type to parse: (Text or ByteString)

The third reason is that read comes from the Read type class, which has no well-defined semantics. In an ideal case, read and show would be inverses but this is just not the reality. See UTCTime as an example.

toEnum

The toEnum :: Enum => Int -> a function is partial whenever the Enumerable type a is smaller than Int:

Prelude> toEnum 5 :: Bool
*** Exception: Prelude.Enum.Bool.toEnum: bad argument
Prelude Data.Word> toEnum 300 :: Word8
*** Exception: Enum.toEnum{Word8}: tag (300) is outside of bounds (0,255)

succ and pred

These are partial, on purpose. According to the docs:

The calls succ maxBound and pred minBound should result in a runtime error.

Prelude Data.Word> succ 255 :: Word8
*** Exception: Enum.succ{Word8}: tried to take `succ' of maxBound
Prelude Data.Word> pred 0 :: Word8
*** Exception: Enum.pred{Word8}: tried to take `pred' of minBound

Use something like (succMay](https://hackage.haskell.org/package/safe-0.3.19/docs/Safe.html#v:succMay).

Functions involving division

• quot
• div
• rem
• mod
• divMod
• quotRem

Prelude> quot 1 0
*** Exception: divide by zero
Prelude> minBound `quot` (-1) :: Int
*** Exception: arithmetic overflow
Prelude> div 1 0
*** Exception: divide by zero
Prelude> minBound `div` (-1) :: Int
*** Exception: arithmetic overflow
Prelude> rem 1 0
*** Exception: divide by zero
Prelude> mod 1 0
*** Exception: divide by zero
Prelude> divMod 1 0
*** Exception: divide by zero
Prelude> quotRem 1 0
*** Exception: divide by zero

Whenever you consider using division, really ask yourself whether you need division. For example, you can (almost always) replace a `div` 2 <= b by a <= 2 * b. (If you're worried about overflow, then use a bigger type.)

If your use-case has a fixed (non-0) literal denominator, like a `div` 2, and you have already considered using something other than division, then your case constitutes an acceptable exception.

Note that integer division may not be what you want in the first place anyway:

Prelude> 5 `div` 2
2 -- Not 2.5

See also https://github.com/NorfairKing/haskell-WAT#num-int

minimum and maximum

These functions throw an exception in pure code whenever the input is empty:

Prelude> minimum []
*** Exception: Prelude.minimum: empty list
Prelude> maximum []
*** Exception: Prelude.maximum: empty list
Prelude> minimum Nothing
*** Exception: minimum: empty structure
Prelude> minimum (Left "wut")
*** Exception: minimum: empty structure
Prelude Data.Functor.Const> minimum (Const 5 :: Const Int ())
*** Exception: minimum: empty structure

The same goes for minimumBy and maximumBy.

You can use minimumMay from the safe package (or a case-match on the sort-ed version of your list, if you don't want an extra dependency).

Applies to Data.Text.maximum and Data.Text.minimum as well

Data.Text.Encoding.decodeUtf8

Throws on invalid UTF-8 datao use Data.Text.Encoding.decodeUtf8' instead.

Functions that throw exceptions in pure code on purpose

throw

Purposely throws an exception in pure code.

Prelude Control.Exception> throw $ ErrorCall "here be a problem"
*** Exception: here be a problem

Don't throw from pure code, use throwIO instead.

undefined

Purposely fails, with a particularly unhelpful error message.

Prelude> undefined
*** Exception: Prelude.undefined
CallStack (from HasCallStack):
  error, called at libraries/base/GHC/Err.hs:80:14 in base:GHC.Err
  undefined, called at <interactive>:1:1 in interactive:Ghci1

Deal with errors appropriately instead.

Also see error below.

error

Purposely fails, with an only slightly less unhelpful error message than undefined.

Prelude> error "here be a problem"
*** Exception: here be a problem
CallStack (from HasCallStack):
  error, called at <interactive>:4:1 in interactive:Ghci1

Deal with errors appropriately instead.

If you're really very extra sure that a certain case will never happen. Bubble up the error to the IO part of your code and then use throwIO or die.

Functions that do unexpected things

realToFrac

This function goes through Rational:

-- | general coercion to fractional types
realToFrac :: (Real a, Fractional b) => a -> b
realToFrac = fromRational . toRational

Rational does not have all the values that a Real like Double might have, so things will go wrong in ways that you don't expect:

Prelude> realToFrac nan :: Double
-Infinity

Avoid general coercion functions and anything to do with Double in particular.

See also https://github.com/NorfairKing/haskell-WAT#real-double

%: Rational values

The % function is used to construct rational values:

data Ratio a = !a :% !a  deriving Eq

Prelude Data.Int Data.Ratio> 1 % 12 :: Ratio Int8
1 % 12

There are constraints on the two values in Rational values:

Recall (from the docs); "The numerator and denominator have no common factor and the denominator is positive."

When using fixed-size underlying types, you can end up with invalid Ratio values using Num functions:

Prelude Data.Int Data.Ratio> let r = 1 % 12 :: Ratio Int8
Prelude Data.Int Data.Ratio> r - r
0 % (-1)
Prelude Data.Int Data.Ratio> r + r
3 % (-14)
> r * r
1 % (-112)

When using arbitrarily-sized underlying types, you can end up with arbitrary runtime:

(1 % 100)^10^10^10 :: Rational -- Prepare a way to kill this before you try it out.

Ratio values create issues for any underlying type, so avoid them. Consider whether you really need any rational values. If you really do, and you have a clear maximum value, consider using fixed-point values. If that does not fit your use-case, consider using Double with all its caveats.

fromIntegral

fromIntegral has no constraints on the size of the output type, so that output type could be smaller than the input type. In such a case, it performs silent truncation:

> fromIntegral (300 :: Word) :: Word8
44

fromIntegral has also had some very nasty bugs that involved the function behaving differently (even partially) depending on optimisation levels. See GHC #20066 and GHC #19345.

Avoid general coercion functions but write specific ones instead, as long as the type of the result is bigger than the type of the input.

word32ToWord64 :: Word32 -> Word64
word32ToWord64 = fromIntegral -- Safe because Word64 is bigger than Word32

Prefer to use functions with non-parametric types and/or functions that fail loudly, like these:

• naturalToInteger :: Natural -> Integer
• naturalToWord :: Natural -> Maybe Word
• toIntegralSized

Witness the trail of destruction:

• Bug in System.IO.hWaitForInput because of fromIntegral
• Bug in cryptography-related code because of fromIntegral

I was also pointed to the finitary package but I haven't used it yet.

toEnum

The toEnum function suffers from the following problem on top of being partial.

Some instances of Enum use "the next constructor" as the next element while others use a n+1 variant:

Prelude> toEnum 5 :: Double
5.0
Prelude Data.Fixed> toEnum 5 :: Micro
0.000005

Depending on what you expected, one of those doesn't do what you think it does.

fromEnum

From the docs:

It is implementation-dependent what fromEnum returns when applied to a value that is too large to fit in an Int.

For example, some Integer that does not fit in an Int will be mapped to 0, some will be mapped all over the place

Prelude> fromEnum (2^66 :: Integer) -- To 0
0
Prelude> fromEnum (2^65 :: Integer) -- To 0
0
Prelude> fromEnum (2^64 :: Integer) -- To 0
0
Prelude> fromEnum (2^64 -1 :: Integer) -- To -1 ?!
0
Prelude> fromEnum (2^63 :: Integer) -- To -2^63 ?!
-9223372036854775808

This is because fromEnum :: Integer -> Int is implemented using integerToInt which treats big integers and small integers differently.

succ and pred

These suffer from the same problem as toEnum (see above) on top of being partial.

Prelude> succ 5 :: Double
6.0
Prelude Data.Fixed> succ 5 :: Micro
5.000001
Prelude> pred 0 :: Word
*** Exception: Enum.pred{Word}: tried to take `pred' of minBound
Prelude Data.Ord Data.Int> succ (127 :: Int8)
*** Exception: Enum.succ{Int8}: tried to take `succ' of maxBound

fromString on ByteString

When converting to ByteString, fromString silently truncates to the bottom eight bits, turning your string into garbage.

> print "⚠"
"\9888"
> print (fromString "⚠" :: ByteString)
"\160"

The enumFromTo-related functions

These also suffer from the same problem as toEnum (see above)

Prelude> succ 5 :: Int
6
Prelude Data.Fixed> succ 5 :: Micro
5.000001

Fun