I do not have `-fobject-code`

set in my cabal file.

Adding `cc-options: -fPIC`

to the cabal file does avoid the first problem I encountered, but the second one remains (with GHCi imploring me to report this as a GHC bug).

Sorry to hear that.

Can we correct the documentation then, to acknowledge this exception to the claim that “All arithmetic is performed modulo 2!^n” if that’s not going to be the case?

I have a project that uses two external libraries, namely `-lcrypt`

and `-lpcre`

. Building with `cabal`

and running the resulting executable works as expected, but I'm having trouble starting a REPL in GHCi:

```
% cabal repl
Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0...
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
/usr/bin/ld: dist/build/etamoo/etamoo-tmp/src/cbits/crypt.o: relocation R_X86_64_PC32 against undefined symbol `crypt' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
```

The error suggests I need `-fPIC`

, and this seems to help the `-lcrypt`

case, but now I get:

```
% cabal repl --ghc-options="-fPIC"
Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0...
GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.1 for x86_64-unknown-linux):
Loading temp shared object failed: /tmp/ghc21539_0/libghc21539_2.so: undefined symbol: pcre_callout
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```

FYI the C type of `pcre_callout`

is a little unusual:

`extern int (*pcre_callout)(pcre_callout_block *);`

In other words it is a global variable (pointer to function), not a function itself.

Any advice is welcome, including the proper way to start GHCi given these external dependencies, as well as on this apparent bug.

Trac field | Value |
---|---|

Version | 7.10.1 |

Type | Bug |

TypeOfFailure | OtherFailure |

Priority | normal |

Resolution | Unresolved |

Component | GHCi |

Test case | |

Differential revisions | |

BlockedBy | |

Related | |

Blocking | |

CC | hvr |

Operating system | |

Architecture | x86_64 (amd64) |

As someone who has recently been bitten by this while trying to implement a pure interface to an external library via FFI, I would like to express my enthusiasm for its resolution.

Trac field | Value |
---|---|

CC | → rob@mars.org, simonmar |

May I ask what the next steps for this are? Is the patch likely to be merged into the 7.8 branch? Or does it still warrant further contemplation and discussion?

It seems to me there is a desire for a fixed-precision integer type that throws an exception on overflow rather than performing modulo arithmetic -- in which case, I'd be fine with the present behavior, as long as all other overflow conditions were treated similarly.

But modulo arithmetic is also useful and desirable for some purposes, and I object to an integer type that performs modulo arithmetic in some cases, and throws an exception in others.

Excellent. Thank you!

Replying to [ticket:8695#comment:78515 hvr]:

Fwiw as a precedent, the following C99 program when compiled with gcc or clang, and executed on Linux results in a runtime exception as well:

`#include <stdio.h> #include <inttypes.h> int main(int argc, char *argv[]) { volatile int32_t a = INT32_MIN; volatile int32_t b = -1; volatile int32_t c = a / b; printf("%" PRId32 "\n", c); return 0; }`

In C, the behavior of signed integer operations that overflow is undefined, so this is not unexpected.

In Haskell, we have Data.Int which declares that signed fixed-precision integer arithmetic operations are performed modulo 2!^n, and thus do not overflow. Except `minBound`

quot`(-1)`

violates this rule.

Given that

`quot`

/`div`

is already a partial function due to div-by-zero, and`minBound`

quot`-1`

being the only special case (beside div-by-zero) for (`quot`

/`div`

) which leads to a result outside the`[minBound..maxBound]`

range, so I'd rather have this exception thrown than to have a program which didn't take into account this non-obvious overflow silently misbehaving due to a flipped sign (as you pointed out yourself if I understood you correctly, but then dismissed it as not being worth an exception).

The same argument could be made for many other arithmetic operations, like `minBound * (-1)`

, as well as `minBound - 1`

, `maxBound + 1`

, etc. I don't see any reason to have a special case for `minBound`

quot`(-1)`

.

It happens that the only reason I discovered this behavior and have reported it as a bug is that it unexpectedly caused a program to abort rather than return the (expected) modulo arithmetic result. So a non-obvious and unexpected exception can equally cause a program to misbehave. This can be especially devastating in a server application.

A program that is sensitive to overflow conditions probably ought not be using fixed-precision integers in the first place; `Integer`

would be a better choice.

But despite what you or I might prefer, the fact remains that modulo arithmetic is the documented behavior for signed fixed-precision integers, so I still tend to view the exception thrown by `minBound`

quot`(-1)`

as a bug.

PS: I believe one may as well argue (as an academic exercise) in a parallel way, that

`quotRem`

by 0 could be assigned a value that satisfies the laws from § 6.4.2 as well, thus making it a total function.

While that might be an interesting exercise, the laws I quoted only apply “if `y`

is non-zero”. So I argue the laws *demand* satisfaction when `y`

is `(-1)`

.

Replying to [ticket:8695#comment:78471 carter]:

any changes need to have clear meaning!

For example, why would minBound * (-1) == minBound? Is this an artifact of twos-complement?

I can’t find anything in the Haskell 2010 Language Report that specifically mentions two’s complement representation, however “All arithmetic is performed modulo 2ˆn, where `n`

is the number of bits in the type.” So given a signed integer representation where `maxBound == 2^(n - 1) - 1`

and `minBound == (-maxBound) - 1`

as is the case in GHC, under modulo arithmetic it mathematically follows that `(-minBound) == minBound`

, which is the same as `minBound * (-1) == minBound`

.

```
maxBound == 2^(n - 1) - 1
minBound == (-maxBound) - 1
== (-(2^(n - 1) - 1)) - 1
== (-2^(n - 1)) + 1 - 1
== (-2^(n - 1))
(-minBound) == (-((-maxBound) - 1))
== maxBound + 1
== 2^(n - 1) - 1 + 1
== 2^(n - 1)
== 2^(n - 1) - 2^n -- (mod 2^n)
== (-2^(n - 1))
== minBound
```

Note that it is already true that `minBound * (-1) == minBound`

for all of the signed fixed-precision integer types in GHC. The only change I am proposing is to also have `minBound`

quot`(-1) == minBound`

instead of raising an exception (and likewise for `div`

).

Such a change is consistent with the modulo arithmetic behavior and also satisfies the class method laws of § 6.4.2 from the Language Report:

```
(x `quot` y)*y + (x `rem` y) == x
(x `div` y)*y + (x `mod` y) == x
```

Replying to [ticket:8695#comment:78457 hvr]:

Fwiw, you also have to avoid calling

`quot`

/`div`

with a`0`

-divisor, otherwise a div-by-zero exception is raised. I wonder if this isn't rather a deficiency of the Haskell2010 report, failing to mention that the modulo-semantics make an exception for the`quot`

/`div`

operations.

I think a division-by-zero exception is reasonably well-understood, since there is no value `q = d`

quot`0`

that could be returned in general such that `q * 0 == d`

, even with modulo arithmetic.

Most code performing division with arbitrary operands is well aware of the possibility of a division-by-zero exception, and defensively avoids it. Much less well known or understood, I think, is the possibility of overflow from the singular case of `minBound`

quot`(-1)`

which, if not accounted for, can also break one’s application (and possibly be a vector for denial-of-service attacks…)

I think I’d much rather have `minBound`

quot`(-1) == minBound`

under modulo arithmetic than a justification for the current exception.

According to the documentation for Data.Int, “All arithmetic is performed modulo 2!^n, where n is the number of bits in the type.”

However, this promise is broken by the following exception:

```
Prelude> (minBound :: Int) `quot` (-1)
*** Exception: arithmetic overflow
```

(This also occurs with Int8, Int16, Int32, and Int64, and likewise for `div`

.)

If all arithmetic is performed modulo 2!^n, I would rather expect the above to evaluate to `minBound`

, since after all `minBound * (-1) == minBound`

. The fact that an exception is raised adds an unnecessary burden in pure code to ensure `quot`

(or `div`

) is never called with these specific arguments.

Trac field | Value |
---|---|

Version | 7.6.3 |

Type | Bug |

TypeOfFailure | IncorrectResultAtRuntime |

Priority | normal |

Resolution | Unresolved |

Component | libraries/haskell2010 |

Test case | |

Differential revisions | |

BlockedBy | |

Related | |

Blocking | |

CC | |

Operating system | |

Architecture |