The unix-bytestring package

[Tags: bsd3, library]

Unix/Posix-specific functions for ByteStrings.

Provides ByteString file-descriptor based I/O API, designed loosely after the String file-descriptor based I/O API in System.Posix.IO. The functions here wrap standard C implementations of the functions specified by the ISO/IEC 9945-1:1990 (`POSIX.1') and X/Open Portability Guide Issue 4, Version 2 (`XPG4.2') specifications.

Note that this package doesn't require the unix package as a dependency. But you'll need it in order to get your hands on an Fd, so we're not offering a complete replacement.

[Skip to ReadMe]


Versions0.3.2,, 0.3.3, 0.3.4,, 0.3.5,,, 0.3.6, 0.3.7,,
Dependenciesbase (>=4.1 && <5), bytestring (>= [details]
CopyrightCopyright (c) 2010--2015 wren gayle romano
Authorwren gayle romano
Home page
Source repositoryhead: darcs get
UploadedSat May 30 06:03:21 UTC 2015 by WrenThornton
DistributionsDebian:, NixOS:
Downloads1972 total (102 in last 30 days)
0 []
StatusDocs available [build log]
Last success reported on 2015-06-03 [all 1 reports]




Maintainers' corner

For package maintainers and hackage trustees

Readme for unix-bytestring-


In general, this is a simple package and should be easy to install.
You must have hsc2hs installed in order to compile the package (but
then you probably already do). With the cabal-install program you
can just do:

    $> cabal install unix-bytestring

Or if you don't have cabal-install, then you can use the Cabal library:

    $> runhaskell Setup.hs configure
    $> runhaskell Setup.hs build
    $> runhaskell Setup.hs test
    $> runhaskell Setup.hs haddock --hyperlink-source
    $> runhaskell Setup.hs copy
    $> runhaskell Setup.hs register

The test step is optional and currently does nothing. The Haddock
step is also optional.

FFI Problems

The unix-bytestring package uses standard POSIX header files
<sys/types.h>, <sys/uio.h>, and <unistd.h>. If Cabal has difficulty
finding these files or reports another error, be sure your include
path variables are correct. If the problem persists, contact the

Building for GHC (6.8 and above)

Nothing special to mention. 

Building for Hugs (September 2006)

I haven't actually compiled this for Hugs because I don't have a
new enough version of Cabal for it, but I don't forsee any difficulties.
If you do compile this for Hugs, let the maintainer know how it

When compiling for Hugs, see the following bugs for Cabal's interaction
with ffihugs. These bugs do not currently affect this package, but
this notice is here in case they affect future versions. For more
details and a minimal regression suite, see:


(1) <>
Options in hugs-options aren't passed through to ffihugs, most
importantly -98 and +o are the ones we'd like to pass. For enabling
the +o flag Hugs-Sept06 does not honor:
    pragma    {-# LANGUAGE OverlappingInstances #-}
    pragma    {-# OPTIONS_HUGS +o #-}
    cabal     extensions: OverlappingInstances
And the -98 flag has similar issues. Therefore this is a real

Immediate solution: The options set in hugs-options should be passed
to ffihugs as well. As of Cabal 1.6 they are not passed (verified
by Duncan Coutts). The two programs accept all the same options,
so this is valid.

Ideal solution: Based on the extensions field, Cabal should
automatically determine whether -98 and +o need to be enabled (for
both hugs and ffihugs).

(2) <>
If CPP is being used in conjunction with FFI, then cpp/cpphs is not
called before ffihugs is called. Thus, users must pass an -F flag
to ffihugs in order to declare a code filter (and must pass all
cpp-options to -F manually). For example:

    --ffihugs-option=-F'cpp -P -traditional -D__HUGS__ -D__BLAH__'

This requires duplicating the build specifications, which defeats
the point of Cabal. Also it leads to tricky issues about ensuring
the proper level of quoting/escaping. (e.g. using the plural,
--ffihugs-options=..., breaks it. Wrapping the -F'cpp...' in double
quotes breaks it.)

----------------------------------------------------------- fin.