Hello Bryan, Thanks for catching this! (see also comment below) [...]

commit b092e35f4c99bfab12247e93c7fa478de638276a Author: Bryan O'Sullivan Date: Sat Oct 12 16:45:50 2013 -0700

Fix assumption that RLIM_INFINITY is a simple number

On MacOS X, it is defined as "(((__uint64_t)1 << 63) - 1)", and hence cannot be used inside C preprocessor logic.

...

---------------------------------------------------------------

b092e35f4c99bfab12247e93c7fa478de638276a System/Posix/Resource.hsc | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/System/Posix/Resource.hsc b/System/Posix/Resource.hsc index a0d0d35..58cff6f 100644 --- a/System/Posix/Resource.hsc +++ b/System/Posix/Resource.hsc @@ -95,13 +95,16 @@ packResource ResourceTotalMemory = (#const RLIMIT_AS)

unpackRLimit :: CRLim -> ResourceLimit unpackRLimit (#const RLIM_INFINITY) = ResourceLimitInfinity

[...] I wonder though, how could that even have compiled in the past on OSX if the expanded RLIM_INFINITY macro #define in the LHS pattern wouldn't result in a simple number? Cheers, hvr