Posix.io.bytestring module uses string instead of bytestring about unix HOT 12 CLOSED

Eric Mertens [email protected] 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.

from unix.

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?)

from unix.

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?

from unix.

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 [email protected] 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
.

from unix.

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 [email protected] wrote:

Eric Mertens <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');> 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
.

from unix.

@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 :-)

from unix.

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.

from unix.

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.

from unix.

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.

from unix.

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?

from unix.

• 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.

from unix.

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.

from unix.