This was forgotten in e14fbe2c

Erik de Castro Lopo authored 10 years ago and Herbert Valerio Riedel committed 10 years ago

It seems these two signals have not been working since at least
2009. Detection of these signals seems to have never been added to
the configure.ac script and the code guarded by #ifdef then bit-rotted
(the idiom used to handle these signals seems to have been abandoned
for something simpler/better in 2009). This fix simply handles these
signals the same way the other signals are handled in
System/Posix/Signals.hsc.

Closes #30 and #31

This adds two new functions in `System.Posix.Unistd`

 - `fileAdvise` (aka `posix_fadvise(2)`), and
 - `fileAllocate` (aka `posix_fallocate(2)`)

This is based in part on #7 and has been heavily refactored from its
original patch submission by Ricardo Catalinas Jiménez.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

More fixes for Safe Haskell bounds under GHC 7.10

This adds two new functions in `System.Posix.Unistd`

 - `fileSynchronise` (aka `fsync(2)`), and
 - `fileSynchroniseDataOnly` (aka `fdatasync(2)`)

This is based on part of #7 and has been heavily refactored from its
original patch submission by Ricardo Catalinas Jiménez.

This also bumps version to 2.7.1.0 as a minor version bump is now needed.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

This is needed in case `<unistd.h>` was included before "execvpe.h"
w/o `_GNU_SOURCE` set (on Glibc systems)

Turns out `process` reuses `unix`'s execvpe() implementation,
and the refactoring in f24ba78f
broke process.

iquiw authored 10 years ago and Herbert Valerio Riedel committed 10 years ago

If `PATH` environment variable contains non directory component,
`__hsunix_execvpe()` failed by `ENOTDIR`.

This fixes #11 for all platforms.

The previous code was prone to conflicts with when the platform happens
to expose a `execvpe(3)` implementation in its libc.

This commit renames the internal implementation to `__hsunix_execvpe` as
well as adding an autoconf-detection for the presence of `execvpe(3)`,
in which case `__hsunix_execvpe()` forwards the call to `execvpe(3)`.

Moreover, the code has been cleaned up to remove likely bitrotted CPP
conditionals.

This should fix #22

(This also partially addresses #11 on platforms which have a
libc-provided `execvpe(3)`)

ip1981 authored 10 years ago and Herbert Valerio Riedel committed 10 years ago

On some systems dlopen() is available without libdl (illumos, solaris).
Sometimes libdl.so cannot be loaded by runtime linker, see
https://ghc.haskell.org/trac/ghc/ticket/8713

Closes #8

David Terei authored 10 years ago and Herbert Valerio Riedel committed 10 years ago

Closes #27

[skip ci]

`System.Posix.Files.fileAccess` fails inside OS X sandbox

Fix potential LFS related issues

kgardas authored 10 years ago and Herbert Valerio Riedel committed 10 years ago

The issue is that sys/types.h header on Solaris includes somehow
/usr/include/sys/feature_tests.h which tests if _FILE_OFFSET_BITS
is defined and if not, then it defines it to 32 if we're compiling
32 bit code (x86). This is simply wrong since we'd like to have it
defined to 64. The issue is solved by including HsUnixConfig.h first
which defines _FILE_OFFSET_BITS to 64 and feature_tests.h is later
OK with that.

This makes sure we pick up the LFS version of `truncate` in case `off_t`
is affected by CPP defines such as `_FILE_OFFSET_BITS`.

This fixes the FFI imports to use the proper `CLong` type over the
previous incorrect `COff` type, as using the wrong argument type can
cause problems when the `long` and `off_t` types have different size.

Historic note from the manual page:

  In glibc up to version 2.1.1, the return type of telldir() was off_t.
  POSIX.1-2001 specifies long, and this is the type used since glibc
  2.1.2 (released in 1999).

Disable getlogin tests for the moment (#1487)

This is useful on OS X when its sandboxing mechanism is used, because
that will set errno = EPERM when a file can't be written due to
sandboxing (as opposed to setting it to EACCES when file permissions
deny writing).

The ByteString variant of the access function didn't accept the same
flags as the non-ByteString one, but it makes sense that the OS doesn't
care about which one is being used and returns all error codes for both
variants.

This makes it more obvious why `unix` depends on `time` in the first
place, i.e. for the sole purpose of reusing the `POSIXTime` type.

Merge branch 'sol-fix-getgrgid_r-v3' of https://github.com/kgardas/unix into kgardas-sol-fix-getgrgid_r-v3

Conflicts:
	changelog.md

This patch fixes getGroupEntryForID and getGroupEntryForName on Solaris
The issue on Solaris is that it defines both required getgrgid_r
and getgrnam_r functions as CPP macros which depending on configuration
are mapped to real function implementations with different names.
The issue is solved by using C API calling convention instead of platform
C ABI calling convention.