Posix.io.bytestring module uses string instead of bytestring

[cartazio]

At least for the versions on hackage :(

[glguy]

This is by design, all that this module does it make it possible to open an FD with a RawFilePath which is a bytestring because POSIX doesn't specify any particular encoding for filenames.

Are you proposing to change the purpose of this module?

[cartazio]

More like I was digging into how I'd do posix pipes manipulation and was
suprised. Granted I think bytestring has the ops I need. Just wanted to
ask in a documented way the answer could be reused next time.

That makes sense. Thanks !

On Wednesday, June 1, 2016, Eric Mertens notifications@github.com wrote:

This is by design, all that this module does it make it possible to open
an FD with a RawFilePath which is a bytestring because POSIX doesn't
specify any particular encoding for filenames.

Are you proposing to change the purpose of this module?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#63 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAAQwgWsU8iwlVk37GjzYYYnx4chyvm1ks5qHbZ7gaJpZM4IrkOE
.

[bgamari]

Eric Mertens notifications@github.com writes:

This is by design, all that this module does it make it possible to open an FD with a RawFilePath which is a bytestring because POSIX doesn't specify any particular encoding for filenames.

It perhaps wouldn't be a terrible idea to add a note in the Haddocks
mentioning this.

[cartazio]

Agreed. That's probably a good idea. Better than staying maintainer
folklore. Does the same rule of thin apply to the other .Bytestring
modules?

On Wednesday, June 1, 2016, Ben Gamari notifications@github.com wrote:

Eric Mertens <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> writes:

This is by design, all that this module does it make it possible to open
an FD with a RawFilePath which is a bytestring because POSIX doesn't
specify any particular encoding for filenames.

It perhaps wouldn't be a terrible idea to add a note in the Haddocks
mentioning this.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#63 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAAQwsw-XaDDYw4bqO6BN6_679kpytWTks5qHfGDgaJpZM4IrkOE
.

[hvr]

@cartazio see top of http://hackage.haskell.org/package/unix-2.7.2.0/docs/System-Posix-ByteString.html

POSIX.1-2008 support with ByteString file paths and environment strings.

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.

@bgamari

It perhaps wouldn't be a terrible idea to add a note in the Haddocks mentioning this.

do we really have to replicate that paragraph in each and every .ByteString-module?

finally, shameless self-plug: with AFPP we wouldn't need the .ByteString API-duplication anymore :-)

[mokus0]

I came across this just now and found it baffling too. I was expecting fdRead, fdWrite, et al, to operate on ByteStrings. I could convert my Fds to Handles but in some applications I specifically want to ultimately use POSIX calls rather than whatever System.IO decides to use (presumably C stdio for portability?)

[hasufell]

My opinion is that ByteString variants shouldn't mess with CString at all (that means convert to ByteString, ShortByteString or something else that's a no-op).

Whether that's a filepath or not doesn't really matter, does it? Most CStrings don't have any pre-defined encoding.

[Bodigrim]

Essentially anything working through peekCString* / pokeCString* should not be present under System.Posix.ByteString tree, because it involves locale-dependent encoding/decoding, but raison d'etre of System.Posix.ByteString is to be locale-independent.

[hasufell]

One of the bigger problems seems to be GroupEntry and UserEntry.

What to do here? Parametrize the type? Add a new type? I think the String type here can in fact lead to security vulnerabilities.

[Bodigrim]

What does POSIX say about username / groupname? Is it just a bytestring with no encoding associated? Or is it supposed to be ASCII subset only?

[hasufell]

• https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pwd.h.html
• https://pubs.opengroup.org/onlinepubs/9699919799/functions/getpwuid.html

I can't see any mention of encoding. It seems it's only implicit that these are NUL terminated. No other guarantees.

[hasufell]

I think most of these instances are fixed. Some boring ones involving error types are still there, but not very interesting. I'll open a new ticket for GroupEntry/UserEntry.