Deprecating fromIntegral

amindfv at gmail.com amindfv at gmail.com
Thu Sep 21 12:35:08 UTC 2017


I'm -1 on this (there are lots of places where you need to know the bounds of the numeric type you're using), but would be fine with adding more documentation to hWaitForInput and/or fromIntegral.

Tom


> El 21 sept 2017, a las 08:24, Niklas Hambüchen <mail at nh2.me> escribió:
> 
> This is not a joke.
> 
> I just found a bug in base (https://ghc.haskell.org/trac/ghc/ticket/14262):
> 
>  import System.IO
>  hWaitForInput stdin 4294968296
> 
> This code should wait for 49.something days, but it waits for 1 second.
> 
> It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt`
> (where CInt = Int32), causing an overflow.
> 
> I argue that `fromIntegral` causes unnoticed data corruption without any
> warning, and thus are worse than partial functions.
> 
> In this case, this data corruption occurs in the most fundamental code
> that we all use and have to rely upon (`base`).
> 
> So I propose that we add a deprecation pragma to `fromIntegral`
> (however, keeping it forever, like Java does, as there's no benefit to
> removing it, we just want that people use safer functions over time),
> and instead provide a `safeFromIntegral` that can only widen ranges, and
> one or more `unsafeFromIntegral` or appropriately named functions that
> can error, wrap, return Maybe, or have whatever desired behaviour when
> the input value doesn't fit into the output type.
> 
> For some inspiration, `foundation` provides ideas in that direction:
> 
> http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html
> http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-IntegralConv.html
> 
> It is a bit funny how we argue that Haskell is good for high assurance
> programming, and we build all sorts of fancy constructs to eliminate
> more run-time errors, when in fact we do worse than C in detecting
> errors in the most basic types a computer can use, such as converting
> between 64-bit and 32-bit integers.
> 
> Let's fix that.
> 
> It avoids real problems in real production systems that are difficult to
> debug when they happen (who writes a unit test checking that a timeout
> of 50 days still works? This is the kind of stuff where you have to rely
> on -- very basic -- types).
> 
> I'd like to probe support for such a change before doing any work on it.
> 
> Niklas
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


More information about the Libraries mailing list