why there are so many unistd.h and under what circumstances should I
include each of them?
appreciate your help,
miloody
You should only use /usr/include/unistd.h which is included with:
#include <unistd.h>
Others are Linux-specific internal headers.
e.g. It looks like /usr/include/bits/unistd.h contains some inline functions and is conditionally included by /usr/include/unistd.h in cases where these functions should be inlined.
Never include it directly. It should make an error!
> #ifndef _UNISTD_H
> # error "Never include <bits/unistd.h> directly; use <unistd.h> instead."
> #endif
linux/unistd.h is a Linux specific header file containing symbolic constants for system call numbers and may be included by assembly source code.
asm/unistd.h, asm/unistd_32.h and asm/unistd_64.h are internally used by linux/unistd.h, with conditional directives, depending on target machine architecture. You should not mess with these 3 files.
sys/unistd.h simply includes unistd.h. It's probably there for compatibility with some old platform which used <sys/unistd.h> rather than <unistd.h>. I don't know the exact story behind this one.
Consequently, you should ONLY include <unistd.h> in normal C programs.
If you write low-level Linux-specific functions needing system call numbers, you may include <linux/unistd.h>.
Other headers should not be included directly.
--
André Gillibert
miloody <mil...@gmail.com>
on Tuesday 25 August 2009 07:39
wrote in comp.unix.programmer:
> Dear all:
> I am reading the book "advance programming in UNIX" and it say
> unistd.h is posix symbolic constants.
Not at all... look at the SUSv2 and SUSv3 specifications:
- -----8<----------8<----------8<----------8<-----
The <unistd.h> header defines miscellaneous symbolic constants and types,
and declares miscellaneous functions. The actual values of the constants
are unspecified except as shown. The contents of this header are shown
below.
- -----8<----------8<----------8<----------8<-----
As you see, the header must be included as <unistd.h>, this means that
it must be present in the system include path. In other words, it could
be located in /usr/include. The other unistd.h files are system specific
files. You could take a look on them ;)
> I find all the unistd.h on my environment:
> /usr/include$ find ./ -name 'unistd.h'
> ./asm/unistd.h
> ./sys/unistd.h
> ./unistd.h
> ./bits/unistd.h
> ./linux/unistd.h
> /usr/include$
>
> why there are so many unistd.h and under what circumstances should I
> include each of them?
Nop, just the <unistd.h> header file must be included. I think that
the <linux/unistd.h> file is related to the Linux kernel and must be
used in kernel development.
Some important constants in <unistd.h> are: _POSIX_VERSION,
_POSIX2_VERSION and _XOPEN_VERSION --- depending on your implementation.
> appreciate your help,
> miloody
Best regards,
- --
.O. | Daniel Molina Wegener | FreeBSD & Linux
..O | dmw [at] coder [dot] cl | Open Standards
OOO | http://coder.cl/ | FOSS Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iQIcBAEBCgAGBQJKk9zAAAoJEHxqfq6Y4O5N4MgQANxUDXOGZ+5SmRhfvUMaylgJ
4WvsXu69qChdGROQ6Us7og9eubJY53Sex6EGPeWVZOaM9c1Ho7PT5Wl4clu54w9k
pT51xqyb90B8aOLJ7d6esOq/zxedJZFNS9rzEXxW2f1BOq7jF8HLxisoxRYM1KkK
YkL5GzbZjzA0DCMZr8UVXHM7pohRslE3T9mvWM0gaX19AZ2KiX1u4kJf/H4yNy3g
Oa5mgKdv5RBa22U2FgT66NC1wgZE0Kgx6wOu8bPuTkUfjgtvYyR2J3j6skdR+Qfl
VbK2BBOs9Cyaly+bySOjt9rJysCAmBOTkR30YlxFB8Au+H9Tfait+k/dzlXhUiaZ
nkQ/pbjVqA4T38bE4sTVYTNxFk8kS449F38IOUAEOgHyEu6VUQFOX9L9r4PROqmH
iSHycVZT6eE8E0SIyT2cj8IOiiunlrBJZC0l2z7YlTigyJJFT/l+AQW7xQFfVa0F
KNYdS1zCqS8bUeO6bUtvj8P5eIbJFmofjenxOpjI9keLsg6pn4VMhjd0JM8CyZO0
nDX9Pm9A99xvMZNbw6ZkxoJye6qsmnBYIIlpMoLEj2tUVXx3xQ3qEmV7RPNNQQpj
V03zyrHJIEvGbnDtn/ksdO6Bs47V2ZShRNcfrEnJDg8IFrCh4tCeUxlj1E6nUIyR
XxtrUHy+1393/qvfxlnl
=3+tG
-----END PGP SIGNATURE-----
> why there are so many unistd.h
Who knows. It's an implementation issue.
> and under what circumstances should I include each of them?
You include <unistd.h>, and that is all. The compiler will look
for it wherever it thinks appropriate (probably /usr/include).
Anything else is just implementation details.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34