In my comprehension the open and the close system call seem very much related.

  • both deal with files
  • available in most all unix flavours (?any unix that does not feature them existed?)

I therefore expected to find them declared both in the /usr/include/unistd.h header file. However -strangely- there is only "close", but no "open" declared there (on my 4.17 linux kernel system)?

The omission of the open system call in unistd.h seems confirmed reading the The Open Group Base Specifications Issue 7, 2018 edition

which tells in paragraph "Declarations"

The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided.

int access(const char *, int);
unsigned alarm(unsigned);
int chdir(const char *);
int chown(const char *,> uid_t, gid_t);
int close(int);
[... some more declarations, but no "open"]

Then -stangely to me again - the file /usr/include/asm/unistd_64.h contains the line

#define __NR_open 2

as if unistd.h still cared somewhat about "opening of files"?

  • 1
    I don’t know the answer to the POSIX question (apart from historical reasons; open is defined in fcntl.h), but I do know that /usr/include/asm/unistd_64.h isn’t related to unistd.h, it’s the fallback list of 64-bit syscall numbers on Linux. Jul 21, 2018 at 11:16

1 Answer 1


The background is that you need to

#include <fcntl.h>

in order to get the open() related flags anyway, and there should be a chance not to pollute the name space more than needed.

If open() would be in unistd.h, this file would need to #include fcntl.h and this is not wanted as a default.

The file unistd_64.h is an inofficial vendor internal include file and what's inside this file is not subject of the POSIX stdandard.

  • In addition, POSIX allows fcntl.h to include unistd.h itself. But is there any rationale to all this beyond “that’s how it was, now we have to live with it”? Jul 21, 2018 at 16:46
  • Not really, POSIX allows to make some symbols from unistd.h visible. This allows to include official and inofficial sub-include files like sys/types,h and sys/unistd.h.
    – schily
    Jul 21, 2018 at 16:51
  • “Inclusion of the <fcntl.h> header may also make visible all symbols from <sys/stat.h> and <unistd.h>.” Also, in what sense is sys/types.h unofficial? But I was more interested in the second part of my comment. Jul 21, 2018 at 17:08
  • sys/unistd.h is unofficial, files like that exist in order to make the POSIX rules easier to implement. This is needed since POSIX decided to make auto inclusion of all needed parts mandatory and there still was the wish to limit the visible symbols.
    – schily
    Jul 21, 2018 at 18:12
  • I never said anything about sys/unistd.h, but never mind. Jul 21, 2018 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.