The logic behind the C standard header files

[Francis Moreau]

Hello,

I'd like to understand this topic.

For example I need to use open, read functions that operate on a
file. I would think to need to include only one header file for these
functions but instead I need to include unistd.h and fcntl.h.

Could anybody explain me why ?

Thanks

Francis

 

[Joachim Schmitz]

Hello,

I'd like to understand this topic.

For example I need to use open, read functions that operate on a
file. I would think to need to include only one header file for these
functions but instead I need to include unistd.h and fcntl.h.

Neither is a C-Standard header. Nor are open() or write() C-Standard
functions.
They are POSIX though, and you may discuss them in comp.unix.programmer

Other than that: for the C-Standard there exists a document called
Rationale, it may give answers to questiones like yours (although not to
your current questions, for the reasons given)

Google found this for me:
http://www.lysator.liu.se/c/rat/title.html

Bye, Jojo

 

[James Kuyper]

Hello,

I'd like to understand this topic.

For example I need to use open, read functions that operate on a
file. I would think to need to include only one header file for these
functions but instead I need to include unistd.h and fcntl.h.

Could anybody explain me why ?

As far as C in concerned, all you need is <stdio.h>. That's sufficient
to open a file, read from it, write to it, move around within the file,
and to close it, plus a few other features as well.

The things that you need <unistd.h> and <fcntl.h> for are not part of C
itself, but are instead related to Unix. If you want to use
operating-system specific functions, you'll generally have to #include
OS-specific header files containing their declarations.

 

[Francis Moreau]

Neither is a C-Standard header. Nor are open() or write() C-Standard
functions.

Sorry I shouldn't have said 'standard' in the subject.

They are POSIX though, and you may discuss them in
comp.unix.programmer

OK.

thanks

Francis

 

[Francis Moreau]

Francis Moreau wrote:
The things that you need <unistd.h> and <fcntl.h> for are not part of
C itself, but are instead related to Unix. If you want to use
operating-system specific functions, you'll generally have to #include
OS-specific header files containing their declarations.

ok but the question was why 2 different headers...

But as someone told me this is not the right place to ask since these
functions are POSIX.

Thanks

Francis

 

[Martin Ambuhl]

Hello,

I'd like to understand this topic.

For example I need to use open, read functions that operate on a
file. I would think to need to include only one header file for these
functions but instead I need to include unistd.h and fcntl.h.

Could anybody explain me why ?

If you are writing standard C, you don't need to include unistd.h or
fcntl.h. In fact, they don't exist in C at all. If you have them, they
are a feature of your implementation. The standard header for functions
that operate on files is <stdio.h>.

You might ask, then, why don't open() and read() work with the inclusion
of <stdio.h>? They don't work because they are not part of the standard
C library. If you have them, they are system-specific functions
provided in some non-standard library. The standard C function for
opening a file is fopen() and the standard C functions for reading a
file include -- among a number of others -- fread().

If you really feel you need open(), read(), unistd.h, and fcntl.h, your
question belongs in an implementation or OS-specific newsgroup, as the
name unistd.h might suggest to you. If you want to use the standard C
library, then your questions are just fine here. But you need to decide
for yourself which path you will take. The standard functions, in
addition to being topical here, provide you with the ability to move to
any other implementation supporting the standard C library. That is not
true of your unix-specific headers and functions any more than it would
be true of windows-specific headers and functions.

 

[CBFalconer]

I'd like to understand this topic.

For example I need to use open, read functions that operate on a
file. I would think to need to include only one header file for
these functions but instead I need to include unistd.h and fcntl.h.

Could anybody explain me why ?

Not here. Those header files do not exist in standard C, nor do
the open, read, write functions. So questions about them are
off-topic on c.l.c. You might try comp.unix.programmer.

Standard C has fread, fwrite, fopen, fclose, for example. They are
all accessed by "#include <stdio.h>".

 

[S M Ryan]

Hello,

I'd like to understand this topic.

For example I need to use open, read functions that operate on a
file. I would think to need to include only one header file for these
functions but instead I need to include unistd.h and fcntl.h.

Could anybody explain me why ?

Because that's the way it's done. It isn't about logic; it's about someone long
ago decided to do what seemed best at that time, and now it's stuck that way.

You can always do your own header, perhaps unix.h, which has
#include <fcntl.h>
#include <sys/types.h>
#include <unistd.h>

and then in all your projects just do
#include "unix.h"

 

[Ben Bacarisse]

That's the answer. It is actually permitted to stuff stdio.h out with
POSIX functions, but it is not a good idea, since you step over the
user's namespace, and sow confusion about what is portable and what is
not.
A few functions like isnan() and identifiers like M_PI have found
their way into gcc's standard header files, and these cause problems
enough.

In my experience it is invoking the compiler in non-standard mode that
causes problems. Do you know of any "stray" identifiers that exist in
standard mode? If so, I'll gladly submit a bug report if you'd rather
not do so yourself.

 

[James Kuyper]

gcc *.c -lm
is the limit of my technical ability.

You need a minimum of -ansi -pedantic for C89 conformance; replace -ansi
with -std=c99 for C99 conformance. Any non-conformance that you see when
you don't use those options is your fault, not theirs, because gcc makes
no claim to conform to any standard in default mode.

 

[Ben Bacarisse]

gcc *.c -lm

is the limit of my technical ability.

Just adding -pedantic -std=c89 (or -std=99) will ensure that your code
does not use anything that gcc just decided to allow for whatever
reason (and some of them are good reasons).

[BTW isnan should be defined in math.h with -std=c99 (and gcc does so)
whilst it should not be defined when using -std=c89 (and again gcc
gets this right). M_PI should not be defined by any standard C
header.]

 

[Nick Keighley]

... but not sufficient for using vprintf.

why not? And who mentioned vprintf() anyway?

 

[James Kuyper]

why not? And who mentioned vprintf() anyway?

Because you also need <stdarg.h> in order to use vprintf(), and I think
that it should be #included prior to <stdio.h>.

While vprintf() was not explicitly mentioned, I made the claim that
<stdio.h> was the only thing that Francis needed for his purposes. The
OP only mentioned opening and reading a file, so vprintf() is not
implied. However, vscanf() could be one of the things he might need (or
at least benefit from) for reading from a file. Like vprintf(), it also
needs <stdarg.h>.

It's pretty unlikely that anyone asking elementary questions like this
will be making use of anything as advanced as vscanf() any time soon.
However, my claim was "all you need", which is a pretty sweeping claim,
and Pete was right to point out that there are I/O functions that also
require <stdarg.h>.