John's first suggested alternative above seems very appealing to me, as it
seems neatly to fix the fundamental design flaw in `errno`: that
determining the success/failure of a system call is separated from the call
itself.
Slightly off-topic but it reminds me of one of my pet peeves with
John Meacham wrote:
I was thinking about this too but had a different idea, an alternate
calling form which grabbed the result of errno and returned it to
haskell land. that way the cost of geting errno is only paid for those
foreign imports which care about it. like
foreign import
Dean Herington [EMAIL PROTECTED] writes:
foreign import ccall_errno unistd.h chdir :: Ptr CChar - IO (CInt,CInt)
John's first suggested alternative above seems very appealing to me, as it
seems neatly to fix the fundamental design flaw in `errno`: that determining
the success/failure of a
Dnia pi 25. lipca 2003 16:52, Dean Herington napisa:
John's first suggested alternative above seems very appealing to me, as it
seems neatly to fix the fundamental design flaw in `errno`: that
determining the success/failure of a system call is separated from the call
itself. I'm surprised
