#include vs. -library

[Tom Impelluso]

Hello,

This is a question about CATEGORIES of functions in C.

There are some C functions that require both a header and a library link:
exp(), sin(): #include<math.h> and -lm

There are some C functions that require JUST a header: malloc(),
fprintf(): #include<stdlib> or stdio.h

There are some C functions that require neither printf()
(actually, printf technically requires the #include, but if I do
not exploit the return value, I do not have to include it to
prototype the function)

Could someone tell me if these functions fall into NAMED categories?
Why was the language created so that there is this apparent asymmetry
in the use of functions: with regard to when to link a library
and when to include?

I understand the NEED to include headers... and libraries... But I am
only searching for why there is this apparent lack of balance....
i.e: What are the categories of these functions in C?

And, as a further example, there is the sleep(); function.
What TYPE of function is that (I know what it does, but why is
there no include and no library at all?)

thanks
t.

 

[Antoninus Twink]

There are some C functions that require both a header and a library link:
exp(), sin(): #include<math.h> and -lm

There are some C functions that require JUST a header: malloc(),
fprintf(): #include<stdlib> or stdio.h

The difference is for historical reasons. Since there are lots of math
functions, and they are never used in a lot of programs, back in the old
days when computers were much slower than they are now some vendors
thought it would be a good idea to separate out these functions into a
separate math library (even though they're in the Standard C Library),
so that programs that don't use them could be compiled more quickly.

And, as a further example, there is the sleep(); function.
What TYPE of function is that (I know what it does, but why is
there no include and no library at all?)

You should #include <unistd.h> if you use sleep(). Again it will depend
on the implementation, but typically most of the standard POSIX
functions just land up in libc and so get linked automatically without
any need to spell it out on the command line.

 

[Ben Bacarisse]

This is a question about CATEGORIES of functions in C.

There are some C functions that require both a header and a library link:
exp(), sin(): #include<math.h> and -lm

What was wrong with the answers you got when you last posted this to
another group? They seemed to be both accurate and complete to me.

 

[Guest]

you are confusing (though it *is* confusing) headers and libraries.
Headers (.h files) hold the "descriptions" of the functions.
The technical term is the functions' DECLARATIONs. The library
source code version (human readable) is in the .c file.
This is technically known as the functions' DEFINITIONs.
The executable code is in .o or .a files (on Unix). You
actually need both header and executable to use a library function.

This is a question about CATEGORIES of functions in C.

There are some C functions that require both a header and a library link:
exp(), sin():  #include<math.h> and -lm

yes, you require both

There are some C functions that require JUST a header: malloc(),
fprintf():  #include<stdlib> or stdio.h

to some extent this is an historical accident. Unix systems
put most of the library functions in a standard library
which is automatically 'included' (linked in). The math.h
functions are not included in this library.

There are some C functions that require neither printf()
no

(actually, printf technically requires the #include, but if I do
not exploit the return value, I do not have to include it to
prototype the function)

yes you do. You might get away with it with non-varargs functions
but doing it with varargs stuff, like printf(), technically
invokes Undefined Behaviour. UB is bad as it means the implementor
(the compiler writer) is permitted, by the standard, to do what he
likes.

Always include the appropriate header file.

Could someone tell me if these functions fall into NAMED categories?
Why was the language created so that there is this apparent asymmetry
in the use of functions: with regard to when to link a library
and when to include?

I assume the math library was relativly expensive and
rarely used, so it was made optional.

I understand the NEED to include headers... and libraries... But I am
only searching for why there is this apparent lack of balance....
i.e: What are the categories of these functions in C?

And, as a further example, there is the sleep(); function.
What TYPE of function is that (I know what it does, but why is
there no include and no library at all?)

sleep() is not part of standard C. There will be an implementation
specific header and library. See your implementaion (Unix?)
documentaion for details.

 

[Tom Impelluso]

your answer there was not complete. These answers are complete...
I am trying to understand the categories.

 

[jameskuyper]

your answer there was not complete. These answers are complete...
I am trying to understand the categories.

Those categories are implementation-specific; the C standard says
nothing about what commands you need to issue to make an
implementation translate your source code. In particular, it doesn't
tell you what command line options you need to use to put a given
implementation into a mode where it fully conforms to the C standard.
People tend to think that "the implementation" refers to the compiler,
but actually it refers to everything you need in order to translate
and execute your C source code. In particular, on typical systems, it
includes the linker. On many systems, the implementation is
technically not fully conforming if you don't use the -lm option;
though you will notice this only if you actually use the <math.h>
routines.

While this is implementation-specific, many different implementations
have this same feature. The reason for that is that the <math.h>
routines were numerous, complicated, and many programs made no use of
them. Therefore, putting them in a seperate library that was not
loaded automatically sped up the link phase for those programs. The
time savings used to be fairly significant, but on modern machines
they're pretty much completely negligible.

In C90, if you referred to a function without a function declaration
in scope, it would be implicitly declared as function returning 'int'
that takes an unknown but fixed number of arguments. For non-variadic
functions that returned either 'int' or another type that was
compatible with 'int', relying on this implicit declaration was safe,
reliable, and portable, so long as you were careful to make sure that
the promoted type of every argument was compatible with the type of
the corresponding parameter. However, it's tricky determining whether
or not such a function call will actually work safely and portably, so
it was never a good idea to rely on this. That's why the category of
functions for which this could be done have never received any special
name: this technique shouldn't be used, so there's no need to know
which functions fall into that category.

In C99, implicit int was dropped, so that category is now officially
empty - and good riddance. You must always have a declaration in scope
for any function you call. There's absolutely no reason not to use the
declarations provided by the corresponding standard header, when
calling standard library functions.

 

[Erik Trulsson]

Hello,

This is a question about CATEGORIES of functions in C.

There are some C functions that require both a header and a library link:
exp(), sin(): #include<math.h> and -lm

There are some C functions that require JUST a header: malloc(),
fprintf(): #include<stdlib> or stdio.h

There are some C functions that require neither printf()
(actually, printf technically requires the #include, but if I do
not exploit the return value, I do not have to include it to
prototype the function)

Not correct. *All* the functions mentioned above need a library when linking.
Most C compilers automatically link against a library containing many of the standard
functions without the user having to mention it explicitly.
Some of the functions are often, for historical reasons, separated into
separate libraries that need to be linked against explicitly by the user.

Which libraries need to be mentioned explicitly, and which are linked
against automatically, depends on the C implemantation (i.e. the compiler,
the linker and the operating system.)

Could someone tell me if these functions fall into NAMED categories?
Why was the language created so that there is this apparent asymmetry
in the use of functions: with regard to when to link a library
and when to include?

I understand the NEED to include headers... and libraries... But I am
only searching for why there is this apparent lack of balance....
i.e: What are the categories of these functions in C?

As far as the C language itself is concerned there is no difference between
the functions you have mentioned: You will have to include the correct header
file to get the prototype or declaration for each of them, and will have to link
against the correct library to get the definition of the function.
How this linking is done varies between implementations.

And, as a further example, there is the sleep(); function.
What TYPE of function is that (I know what it does, but why is
there no include and no library at all?)

sleep() is not part of the C language proper, but rather an extension
available in many C implementations, but with possibly different syntax and
semantics.

Under Unix, for example, you would have to include <unistd.h> to get the
prototype, and the definition lives in libc, so is automatically linked
against by the compiler.

Other system may need different includes or libraries, or may not provide a
sleep() function at all.

 

[jfbode1029]

Hello,

This is a question about CATEGORIES of functions in C.

There are some C functions that require both a header and a library link:
exp(), sin():  #include<math.h> and -lm

This is an historical quirk of your particular development
environment, not a function of the C language itself. Not all
compilers/linkers require you to link the math library explicitly.

There are some C functions that require JUST a header: malloc(),
fprintf():  #include<stdlib> or stdio.h

This is because the machine code for those functions is linked into
the executable by default.

There are some C functions that require neither printf()
(actually, printf technically requires the #include, but if I do
not exploit the return value, I do not have to include it to
prototype the function)

You need the prototype in scope regardless of whether you use the
return value because printf() *requires* the first parameter to be
typed const char * restrict, and without the prototype in scope the
compiler cannot catch a type mismatch if you somehow forget the format
string.

Could someone tell me if these functions fall into NAMED categories?

Well, you can distinguish between functions that are part of the
standard library (everything in assert, ctype, errno, locale, math,
setjmp, signal, stdarg, stddef, stdio, stdlib, string, time, wchar,
wctype, etc., even if the machine code for them is distributed among
different physical library files) and those functions that are part of
a third-party library or utility (such as system calls for a
particular OS, or APIs for GUI frameworks, etc.). The former will be
part of every (hosted) C implementation, the latter may not be.

Why was the language created so that there is this apparent asymmetry
in the use of functions: with regard to when to link a library
and when to include?

Again, this is a function of the *development environment* (compiler,
linker, etc.), not the language. As far as C is concerned, there's no
difference between cos() and printf() other than their types and
parameters. Each compiler vendor is free to define the mechanics of
how the machine code for each becomes part of the final executable.

I understand the NEED to include headers... and libraries... But I am
only searching for why there is this apparent lack of balance....
i.e: What are the categories of these functions in C?

And, as a further example, there is the sleep(); function.
What TYPE of function is that (I know what it does, but why is
there no include and no library at all?)

There is, it's just specific to your particular environment (assuming
a Linux system, it should declared in unistd.h and be part of libc;
I'm not sure what library it's defined in).

 

[Keith Thompson]

This is a question about CATEGORIES of functions in C.

There are some C functions that require both a header and a library link:
exp(), sin(): #include<math.h> and -lm

There are some C functions that require JUST a header: malloc(),
fprintf(): #include<stdlib> or stdio.h

There are some C functions that require neither printf()
(actually, printf technically requires the #include, but if I do
not exploit the return value, I do not have to include it to
prototype the function)

The language itself (i.e., the ISO C standard) defines no such
categories.

All standard library functions require a #include for the
corresponding standard header. In particular, callling printf()
without a visible prototype invokes undefined behavior.

(Actually, you can also declare any standard library function yourself
rather than #include'ing the header -- *if* you get the declaration
right. And for non-variadic functions returning int, you can
sometimes rely on the implicit declaration -- *if* you're using a C90
compiler; C99 dropped the "implicit int" rule. But there's no good
reason to do this. Just add the #include.)

As for the "-lm" option for math functions, the language says nothing
about that, or anything else about what you need to do to compile and
link a program. It's an implementation detail, and there are
compilers that don't require it.

[...]

And, as a further example, there is the sleep(); function.
What TYPE of function is that (I know what it does, but why is
there no include and no library at all?)

sleep() is not a standard C function. On systems that provide it, if
you don't need to specify a library, that just means that it's
provided in a library that's used by default. And on my system, it
requires a "#include <unistd.h>".

Summary: All library functions require an appropriate #include (you
might be able to get away without it, but you shouldn't). Whether you
need to specify an additional library depends on the function and on
your implementation.

 

[Phil Carmody]

Hello,

This is a question about CATEGORIES of functions in C.

There are some C functions that require both a header and a library link:
exp(), sin(): #include<math.h> and -lm

The C standard does not require you to use a '-lm' switch in order
to link your C code. In fact, the C standard does not even require
that there is a 'linking' phase. It doesn't even require that there
is any compilation, it's perfectly acceptible to interpret C.

What you are seeing is an artefact of your implementation. Ask your
compiler vendor why it has chosen to do things that way; it's nothing
to do with C.

There are some C functions that require JUST a header: malloc(),
fprintf(): #include<stdlib> or stdio.h

There are some C functions that require neither printf()
(actually, printf technically requires the #include, but if I do
not exploit the return value, I do not have to include it to
prototype the function)

That's very bad advice. If you want the declaration for a standard
library function, it's always best to include the standard library
header.

Phil

 

[Phil Carmody]

Not correct. *All* the functions mentioned above need a library when linking.

Not so. The C standards permits there to be such things as libraries,
but does not insist that such things exist. And even on systems which
do make use of libraries (such as peecees), it's not uncommon for
standard library functions such as simple floating point operations
to be replaced by inline opcodes, such that there's no need at all for
a library in order to link that function, as one doesn't need to link
that function.

Phil

 

[Keith Thompson]

The C standard does not require you to use a '-lm' switch in order
to link your C code. In fact, the C standard does not even require
that there is a 'linking' phase. It doesn't even require that there
is any compilation, it's perfectly acceptible to interpret C.

[...]

Well, sort of. Linking is translation phase 8; see C99 5.1.2.2. But
if an implementation can produce the same results without having an
explicit linking phase, that's ok.

 

[Keith Thompson]

Not so. The C standards permits there to be such things as libraries,
but does not insist that such things exist. And even on systems which
do make use of libraries (such as peecees), it's not uncommon for
standard library functions such as simple floating point operations
to be replaced by inline opcodes, such that there's no need at all for
a library in order to link that function, as one doesn't need to link
that function.

Any standard library function can be additionally implemented as a
macro, provided that macro definition satisfies certain requirements.
But there must still be an actual function definition. Neither the
macro definition (if any) nor the actual function definition is
required to be implemented in standard C; it can use whatever
implementation-defined features it likes as long as it behaves as
specified.

For example:

x = sin(y);
/* may invoke a macro, which might use inline assembly
or compiler magic */

x = (sin)(y);
/* must call the actual function, but that function can use
inline assembly or compiler magic -- and the implementation
may also do some magic with the function call, as long as it
behaves as specified. */

double *func_ptr(double) = sin;
x = func_ptr(y);
/* as above, but the compiler is likely to find it more difficult
to do magic with the call itself. */

In all three cases, the implementation may legitimately replace the
call with an inline sine instruction (assuming that such an
instruction exists and that its behavior is compatible with C's
requirements for the sin() function).

 

[Phil Carmody]

The C standard does not require you to use a '-lm' switch in order
to link your C code. In fact, the C standard does not even require
that there is a 'linking' phase. It doesn't even require that there
is any compilation, it's perfectly acceptible to interpret C.

[...]

Well, sort of. Linking is translation phase 8; see C99 5.1.2.2. But
if an implementation can produce the same results without having an
explicit linking phase, that's ok.

Whilst pedantically I should have been corrected, I believe your
correction was not quite right. The linking phase does not have
its implementation in any way defined, only its result. The
implementation is not required to refer to any external entities
called a 'library' in performing this phase. If there's nothing
to be resolved, the phase may be a no-op.

Phil

 

[Phil Carmody]

Any standard library function can be additionally implemented as a
macro, provided that macro definition satisfies certain requirements.
But there must still be an actual function definition. Neither the

"be", eh? I'm not questioning that ontological aspect, you know.

macro definition (if any) nor the actual function definition is
required to be implemented in standard C; it can use whatever
implementation-defined features it likes as long as it behaves as
specified.

For example:

x = sin(y);
/* may invoke a macro, which might use inline assembly
or compiler magic */

x = (sin)(y);
/* must call the actual function, but that function can use
inline assembly or compiler magic -- and the implementation
may also do some magic with the function call, as long as it
behaves as specified. */

double *func_ptr(double) = sin;
x = func_ptr(y);
/* as above, but the compiler is likely to find it more difficult
to do magic with the call itself. */

In all three cases, the implementation may legitimately replace the
call with an inline sine instruction (assuming that such an
instruction exists and that its behavior is compatible with C's
requirements for the sin() function).

Erm, that's all well and good, but doesn't seem to make any reference
to external function references, which are the things that would need
to be resolved in a linking phase.

Compiled translation units aren't obliged to have external function
references of library functions implemented inline are they? Got a
C&V for that?

Phil

 

[Keith Thompson]

The C standard does not require you to use a '-lm' switch in order
to link your C code. In fact, the C standard does not even require
that there is a 'linking' phase. It doesn't even require that there
is any compilation, it's perfectly acceptible to interpret C.

[...]

Well, sort of. Linking is translation phase 8; see C99 5.1.2.2. But
if an implementation can produce the same results without having an
explicit linking phase, that's ok.

Whilst pedantically I should have been corrected, I believe your
correction was not quite right. The linking phase does not have
its implementation in any way defined, only its result. The
implementation is not required to refer to any external entities
called a 'library' in performing this phase. If there's nothing
to be resolved, the phase may be a no-op.

Yeah, I think you're right. My followup was intended more to
illuminate than to disagree; I'm not sure I succeeded.

 

[jameskuyper]

The C standard does not require you to use a '-lm' switch in order
to link your C code. In fact, the C standard does not even require
that there is a 'linking' phase. It doesn't even require that there
is any compilation, it's perfectly acceptible to interpret C.

[...]

Well, sort of. Linking is translation phase 8; see C99 5.1.2.2. But
if an implementation can produce the same results without having an
explicit linking phase, that's ok.

Whilst pedantically I should have been corrected, I believe your
correction was not quite right. The linking phase does not have
its implementation in any way defined, only its result.

That's OK, Keith was only pointing out that "the C standard does" in
fact "require that there is a 'linking' phase". He did not address the
fact that, like all other phases of translation, only the result of
the phase is defined, not the methods by which that result is
achieved. The methods used are outside the scope of the standard.

... The
implementation is not required to refer to any external entities
called a 'library' in performing this phase. If there's nothing
to be resolved, the phase may be a no-op.

Keith cited the wrong section; presumably a typo. The correct section
is 5.1.1.2p1:
"All external object and function references are resolved. Library
components are linked to satisfy external references to functions and
objects not defined in the current translation. All such translator
output is collected into a program image which contains information
needed for execution in its execution environment."

While it does not require that they be external entities (whatever
that means), it most definitely does refer to "library components".

 

[Keith Thompson]

[...]
The C standard does not require you to use a '-lm' switch in order
to link your C code. In fact, the C standard does not even require
that there is a 'linking' phase. It doesn't even require that there
is any compilation, it's perfectly acceptible to interpret C.
[...]

Well, sort of. Linking is translation phase 8; see C99 5.1.2.2. But
if an implementation can produce the same results without having an
explicit linking phase, that's ok.

Whilst pedantically I should have been corrected, I believe your
correction was not quite right. The linking phase does not have
its implementation in any way defined, only its result.

That's OK, Keith was only pointing out that "the C standard does" in
fact "require that there is a 'linking' phase". He did not address the
fact that, like all other phases of translation, only the result of
the phase is defined, not the methods by which that result is
achieved. The methods used are outside the scope of the standard.

I thought I did address that: "But if an implementation can produce
the same results without having an explicit linking phase, that's ok."

Keith cited the wrong section; presumably a typo. The correct section
is 5.1.1.2p1:

You're right, I typoed the section number.

 

[CBFalconer]

.... snip ...

There are some C functions that require neither printf()
(actually, printf technically requires the #include, but if I
do not exploit the return value, I do not have to include it
to prototype the function)

Yes you do. In C99 you need the prototype, else error. In C90 you
need the prototype to mark is as a varargs function. In either
case without the #include your system exhibits undefined behaviour.

 

[Phil Carmody]

[...]
The C standard does not require you to use a '-lm' switch in order
to link your C code. In fact, the C standard does not even require
that there is a 'linking' phase. It doesn't even require that there
is any compilation, it's perfectly acceptible to interpret C.
[...]

Well, sort of. Linking is translation phase 8; see C99 5.1.2.2. But
if an implementation can produce the same results without having an
explicit linking phase, that's ok.

Whilst pedantically I should have been corrected,

I retract that. I do not believe there was a flaw in my original
paragraph.

I thought I did address that: "But if an implementation can produce
the same results without having an explicit linking phase, that's ok."

We're agreed. End of?

Phil