Fixes #35: fd{Read,Write} with ByteString payload

[mmhat]

This commit addes two new functions: fdReadBytes and fdWriteBytes.
They are like fdRead and fdWrite respectively but instead of
reading/writing String they use ByteStrings.

Fixes #35

[hs-viktor]

Is this incidental cleanup, or "essential" to this PR? To be honest I've never taken the time to understand Safe, Trustworthy, ... So I don't know whether this change is correct or belongs in this PR (collateral cleanup is of course OK in some cases).

[mmhat]

Yes, it is need; Otherwise we cannot safely import that module in System.Posix.IO.ByteString.

[hs-viktor]

ByteStrings already carry a length field, there's little point in returning it another copy wrapped in a tuple. This should use createUptoN and return just the ByteString.

Also, not all errors are invalid descriptor or EOF. On a non-blocking file descriptor, the error could be EAGAIN, and fdReadBuf will have thrown the corresponding IO Exception.
I am not sure that raising on EOF is the most useful result, returning an empty ByteString may be a cleaner choice, but perhaps we're too used to EOF exceptions in Haskell... :-(

[mmhat]

Also, not all errors are invalid descriptor or EOF. On a non-blocking file descriptor, the error could be EAGAIN, and fdReadBuf will have thrown the corresponding IO Exception.
I am not sure that raising on EOF is the most useful result, returning an empty ByteString may be a cleaner choice, but perhaps we're too used to EOF exceptions in Haskell... :-(

Not sure yet what my opinion is here; I tried to stick to the existing design (with all its bugs and quirks) here. If we decide to change the way how we handle EOF I suggest we do it in #219 and discuss it over there.

[hasufell]

My opinion is that these shouldn't be new functions, but that the existing functions fdRead/fdWrite in System.Posix.IO.ByteString are buggy, since they don't use ByteString. That means they're in fact the same as their counterparts in System.Posix.IO:

• https://hackage.haskell.org/package/unix-2.7.2.2/docs/System-Posix-IO.html#v:fdRead
• https://hackage.haskell.org/package/unix-2.7.2.2/docs/System-Posix-IO-ByteString.html#v:fdRead

That makes no sense.

So I think breaking API here is the right choice.

[mmhat]

@hasufell I wholeheartedly aggree with you but wanted to be careful with backwards-incompatible changes. If no one objects I'll update this PR such that it fixes this bug and remove the new functions.

[hasufell]

@hs-viktor opinions? Users who use the old functions can fix their code easily by importing the ones from System.Posix.IO instead. I think that's a reasonable migration strategy and can likely be automated for large codebases.

[hasufell]

We could also add a test identical to https://github.com/haskell/unix/blob/master/tests/Posix014.hs

[mmhat]

I opened another PR #219 implementing the fix like @hasufell suggested in #186 (comment).

[mmhat]

We could also add a test identical to https://github.com/haskell/unix/blob/master/tests/Posix014.hs

@hasufell Will add one once we decide which PR will make it.

[Bodigrim]

That means they're in fact the same as their counterparts in System.Posix.IO:

* https://hackage.haskell.org/package/unix-2.7.2.2/docs/System-Posix-IO.html#v:fdRead

* https://hackage.haskell.org/package/unix-2.7.2.2/docs/System-Posix-IO-ByteString.html#v:fdRead

That makes no sense.

On the surface level this is kinda expected, the contract is that System.Posix.ByteString represents all file paths and environment strings as ByteString instead of String, but other arguments or outputs remain unchanged. So functions which take neither file paths nor environment strings are indeed the same in both modules.

unix/System/Posix/ByteString.hs

Lines 16 to 21 in e919c7d

	-- This module exports exactly the same API as "System.Posix", except
	-- that all file paths and environment strings are represented by
	-- 'ByteString' instead of 'String'. The "System.Posix" API
	-- implicitly translates all file paths and environment strings using
	-- the locale encoding, whereas this version of the API does no
	-- encoding or decoding and works directly in terms of raw bytes.

However, the underlying rationale for the existence of System.Posix.ByteString is not performance per se, it's independence from locale encodings. So while it is expected to have some duplicates between System.Posix and System.Posix.ByteString and it is not a crime to be inefficient, locale-dependent decoding should not have place in System.Posix.ByteString.fdRead as it happily happens now. Since there is no way to return String without some kind of decoding (locale-driven or other), these functions should indeed return ByteString. I think a breaking change is justified here.

[hasufell]

Dropped in favor of #219