## Summary `Numeric.readFloat` seems to take time linear in the size of the denoted number. This means that, when run on untrusted input, an attacker can cause the machine to use a great deal of CPU resources to discover that `1e10000000000000000000000000000` denotes `Infinity`. This may not be fixable, given the type signature, but it would be useful to at least warn about this in the Haddocks. This problem has surfaced in at least one real library: https://github.com/brandonchinn178/toml-reader/issues/8 ## Steps to reproduce Open ghci. Type the following sequence of commands: ``` $ ghci GHCi, version 9.4.4: https://www.haskell.org/ghc/ :? for help ghci> import qualified Numeric ghci> Numeric.readFloat "1e1000000" [(Infinity,"")] ghci> Numeric.readFloat "1e10000000" [(Infinity,"")] ghci> Numeric.readFloat "1e100000000" [(Infinity,"")] ghci> Numeric.readFloat "1e100000000" [(Infinity,"")] ghci> Numeric.readFloat "1e1000000000" [(Infinity,"")] ghci> :t Numeric.readFloat "1e1000000000" Numeric.readFloat "1e1000000000" :: RealFrac a => [(a, String)] ``` Each takes approximately ten times as long as the prior to run - the last one takes around 35 seconds (timed with a stopwatch) on my machine. ## Expected behavior I would expect either that the Haddocks would warn about this, or that `Infinity` would be returned quickly. ## Environment * GHC version used: 9.4.4 Optional: * Operating System: Fedora 38 * System Architecture: 64-bit Intel