commentary/cmm-exceptions.md

@@ -26,11 +26,11 @@ Some higher level languages provide facilities to handle these exceptions, inclu
 
 
 
-There has been at least one problem in GHC that would benefit from exception handling--in some cases, for `Integral`s.  See bug ticket [\#1042](https://gitlab.haskell.org//ghc/ghc/issues/1042).  The bug occurs in `show`ing the number, in \[GhcFile(libraries/base/GHC/Show.lhs) GHC.Show\], `showSignedInt`, before conversion from base_2 to base_10, where a negative `Int` (always `Int32`) is negated in order to process it as a positive value when converting it to a string, base_10, causing an overflow error on some architectures.  (Bear in mind that it would show up here in the example for [\#1042](https://gitlab.haskell.org//ghc/ghc/issues/1042) because the function would be evaluated in GHCi here; the negation is the problem and the exception shows up in the *next* instruction on that operand, here `DIV`.)  
+There has been at least one problem in GHC that would benefit from exception handling--in some cases, for `Integral`s.  See bug ticket [\#1042](https://gitlab.haskell.org/ghc/ghc/issues/1042).  The bug occurs in `show`ing the number, in \[GhcFile(libraries/base/GHC/Show.lhs) GHC.Show\], `showSignedInt`, before conversion from base_2 to base_10, where a negative `Int` (always `Int32`) is negated in order to process it as a positive value when converting it to a string, base_10, causing an overflow error on some architectures.  (Bear in mind that it would show up here in the example for [\#1042](https://gitlab.haskell.org/ghc/ghc/issues/1042) because the function would be evaluated in GHCi here; the negation is the problem and the exception shows up in the *next* instruction on that operand, here `DIV`.)  
 
 
 
-The exception example in [\#1042](https://gitlab.haskell.org//ghc/ghc/issues/1042) does not occur on PowerPC machines, which dutifully print the two's complement of `(-2147483648::Int) `div` (-1::Int)`: `0`.  (`-2147483648` is the minimum bound for signed Ints, so negating it should properly become, bitwise, a positive `2147483647` (all but bit 31 set); once negated again when divided by `-1` this would be `0`; `-0` is converted to `0`.)  On some architectures such as Intel 64 and IA-32, negating the minimum bound does not wrap around to `0` but overflows, which is reported as a floating point "overflow" (`#O`) exception: the `NEG` instruction modifies the `OF` flag (bit 11) in the `EFLAGS` register--curiously enough, the `DIV` and `IDIV` instructions have *undefined* effects on the `OF` flag.  
+The exception example in [\#1042](https://gitlab.haskell.org/ghc/ghc/issues/1042) does not occur on PowerPC machines, which dutifully print the two's complement of `(-2147483648::Int) `div` (-1::Int)`: `0`.  (`-2147483648` is the minimum bound for signed Ints, so negating it should properly become, bitwise, a positive `2147483647` (all but bit 31 set); once negated again when divided by `-1` this would be `0`; `-0` is converted to `0`.)  On some architectures such as Intel 64 and IA-32, negating the minimum bound does not wrap around to `0` but overflows, which is reported as a floating point "overflow" (`#O`) exception: the `NEG` instruction modifies the `OF` flag (bit 11) in the `EFLAGS` register--curiously enough, the `DIV` and `IDIV` instructions have *undefined* effects on the `OF` flag.  
 
 
 
@@ -61,7 +61,7 @@ The workaround was to avoid negating `minBound` `Int`s; note that no Intel instr
 
 
 
-There was a long message thread on the Haskell-prime mailing list, "realToFrac Issues," beginning with [ John Meacham's message](http://www.haskell.org/pipermail/haskell-prime/2006-February/000791.html) and ending with [ Simon Marlow's message](http://www.haskell.org/pipermail/haskell-prime/2006-March/000840.html).  The following code for converting a Float to a Double will *fail* to produce a floating point exception or NaN on x86 machines (recall that 0.0/0.0 is NaN *and* a definite FPU exception):
+There was a long message thread on the Haskell-prime mailing list, "realToFrac Issues," beginning with [John Meacham's message](http://www.haskell.org/pipermail/haskell-prime/2006-February/000791.html) and ending with [ Simon Marlow's message](http://www.haskell.org/pipermail/haskell-prime/2006-March/000840.html).  The following code for converting a Float to a Double will *fail* to produce a floating point exception or NaN on x86 machines (recall that 0.0/0.0 is NaN *and* a definite FPU exception):