Axel Simon wrote:
Does anyone know why these are in the IO monad? Aren't they pure functions converting between dotted-decimal strings and a 32-bit network byte ordered binary value?
I guess the answer is no for both: The first one can fail
That doesn't mean that it should be in the IO monad; using Maybe would suffice.
Agreed. Perhaps I wasn't clear enough in my original question. There appears to be no intrinsic reason why they should be in the IO monad.
Hence ntoa needs to be an IO action so that the value is read immediately before the next ntoa call is executed.
That shouldn't be an issue so long as the buffer contents are converted to a Haskell String before the function is called again within the same thread.
However, I wouldn't rely upon all implementations of inet_ntoa() being thread-safe.
What you could do is to apply unsafePerformIO to
[snip]
Or you could just re-implement the functions in Haskell.
Apart from the re-entrancy issues with inet_ntoa(), many implementations of inet_addr() have misfeatures, e.g. allowing octets to be expressed in octal or hex, or allowing numbers outside of the 0-255 range (in which case, the top bits overflow into the next octet).
Perhaps better would be: inet_addr' :: (Octet,Octet,Octet,Octet) -> HostAddress inet_ntoa' :: HostAddress -> (Octet,Octet,Octet,Octet) I see Peter Simons has already written something: http://cryp.to/hsdns/docs/Network.IP.Address.html#v%3Aha2tpl Dominic.