What's the difference between "C system calls" and "C library routines"?

Question

There are multiple sections in the manpages. Two of them are:

2     Unix and C system calls
3     C Library routines for C programs

For example there is getmntinfo(3) and getfsstat(2), both look like they do the same thing. When should one use which and what is the difference?

Answer 1

I want to stress the most important part: Section 2 is system dependent — programs using those functions are not portable.

(To be clear, as interjay pointed out in a comment, most of section 3 isn't strictly portable either — but it contains a portable subset. By contrast, section 2 is explicitly system dependent.)

What made C so successful was its standard library that provided an abstraction layer for common tasks like standard I/O (e.g. printf) and dynamic memory management (e.g. malloc). Programs using only standard library functions should run on any conformant C implementation.

By contrast, programs using functions such as read and write could only run on specific (here: POSIX) systems. While that is a large subset, and many developers in the workstation world take their existence for granted, systems like Windows do not compile such programs out of the box (but instead one has to introduce a POSIX emulation layer like Cygwin).

Of course, the C standard library could only provide the smallest common denominator. Many common tasks like GUI development or elaborate file system access must be accomplished through system specific functions. This is by far the most common reason to use them.

Unsurprisingly, de facto standard libraries like GTK have emerged to fill that gap.

Answer 2

As a general rule, you should always use the C library version. They often have wrappers that handle esoteric things like restarts on a signal (if you have requested that). This is especially true if you have already linked with the library. All rules have reasons to be broken. Reasons to use the direct calls,

1. You want to be libc agnostic; Maybe with an installer. Such code could run on Android (bionic), uClibc, and more traditional glibc/eglibc systems, regardless of the library used. Also, dynamic loading with wrappers to make a run-time glibc/bionic layer allowing a dual Android/Linux binary.
2. You need extreme performance. Although this is probably rare and most likely misguided. Probably rethinking the problem will give better performance benefits and not calling the system is often a performance win, which the libc can occasionally do.
3. You are writing some initramfs or init code without a library; to create a smaller image or boot faster.
4. You are testing a new kernel/platform and don't want to complicate life with a full blown file system; very similar to the initramfs.
5. You wish to do something very quickly on program startup, but eventually want to use the libc routines.
6. To avoid a known bug in the libc.
7. The functionality is not available through libc.

Sorry, most of the examples are Linux specific, but the rationals should apply to other Unix variants. The last item is quite common when new features are introduced into a kernel. For example when kqueue or epoll where first introduced, there was no libc to support them. This may also happen if the system has an older library, but a newer kernel and you wish to use this functionality.

If your process hasn't used the libc, then most likely something in the system will have. By coding your own variants, you can negate the cache by providing two paths to the same end goal. Also, Unix will share the code pages between processes. Generally there is no reason not to use the libc version.

Other answers have already done a stellar job on the difference between libc and system calls.

Answer 3

Libraries of common functions are built on top of the system call interface, but applications are free to use both.

System calls are like authentication keys which have the access to use kernel resources.

Above image is from Advanced Linux programming and helps to understand how the user apps interact with kernel.

Answer 4

The calls described in section 2 of the manual are all relatively thin wrappers around actual calls to system services that trap to the kernel. The C standard library routines described in section 3 of the manual are client-side library functions that may or may not actually use system calls.

This posting has a description of system calls and trapping to the kernel (in a slightly different context) and explains the underlying mechanism behind system calls with some references.

Answer 5

System calls are the interface between user-level code and the kernel. C Library routines are library calls like any other, they just happen to be really commonly provided (pretty much universally). A lot of standard library routines are wrappers (thin or otherwise) around system calls, which does tend to blur the line a bit.

As to which one to use, as a general rule, use the one that best suits your needs.

Answer 6

System calls are operating system functions, like on UNIX, the malloc() function is built on top of the sbrk() system call (for resizing process memory space).

Libraries are just application code that's not part of the operating system and will often be available on more than one OS. They're basically the same as function calls within your own program.

The line can be a little blurry but just view system calls as kernel-level functionality.