Back: Cross-Unix Portability
Forward: Cross-Unix System Interfaces
FastBack: Unix/Windows Portability
Up: Cross-Unix Portability
FastForward: Unix/Windows Portability
Top: Autoconf, Automake, and Libtool
Contents: Table of Contents
Index: Index
About: About this document

15.2.1 Cross-Unix Function Calls

Functions not mentioned in POSIX.1 may not be available on all systems. If you want to use one of these functions, you should normally check for its presence by using `AC_CHECK_FUNCS' in your `' script, and adapt to its absence if possible. Here is a list of some popular functions which are available on many, but not all, modern Unix systems:

There are several portability issues with alloca. See the description of AC_FUNC_ALLOCA in the autoconf manual. Although this function can be very convenient, it is normally best to avoid it in highly portable code.
GNU libtool provides a portable alternate interface to dlopen. See section 17. Dynamic Loading.
In some cases fgets may be used as a fallback. In others, you will need to provide your own version of this function.
On some systems, the page size is available as the macro PAGE_SIZE in the header file `sys/param.h'. On others, the page size is available via the sysconf function. If none of those work, you must generally simply guess a value such as 4096.
When this is not available, fall back to a less precise function such as time or ftime (which itself is not available on all systems).
In some cases you can use either mmap or ordinary file I/O. In others, a program which uses mmap will simply not be portable to all Unix systems. Note that mmap is an optional part of the 1996 version of POSIX.1, so it is likely to be added to all Unix systems over time.
Unix systems without ptrace generally provide some other mechanism for debugging subprocesses, such as `/proc'. However, there is no widely portable method for controlling subprocesses, as evidenced by the source code to the GNU debugger, gdb.
Different Unix systems handle this differently. On some systems, any program can switch between the effective user ID of the executable and the real user ID. On others, switching to the real user ID is final; some of those systems provide the setreuid function instead to switch the effective and real user ID. The effect when a program run by the superuser calls setuid varies among systems.
If this is not available, then in some cases it will be reasonable to simply use sprintf, and in others you will need to write a little routine to estimate the required length and allocate an appropriate buffer before calling sprintf.
You can normally provide your own version of these simple functions.
When this is not available, just use malloc instead.
When this is not available, just use fork instead.

This document was generated by Gary V. Vaughan on February, 8 2006 using texi2html