<p>The simple breakdown is:</p>

<ul>
<li>Anything that performs input/output involes a series of system calls.</li>
<li>Anything that's purely computational doesn't involve system calls.</li>
</ul>

<p>Both of these statements have exceptions (I/O through memory-mapped files or peripherals is I/O without syscalls, calling a hardware accelerator or allocating memory is syscalls without externally visible I/O) but they're a good approximation.</p>

<p>So here are some examples of operations that don't involve system calls:</p>

<ul>
<li>Getting or changing the value of a variable.</li>
<li>Arithmetic operations on integers and floats.</li>
<li>Conditionals and loops whose body doesn't involve system calls.</li>
<li>Operations on strings such as searching, joining, splitting, etc.</li>
<li>Manipulations of data structures such as lists, arrays, matrices, trees, etc.</li>
<li>Memory management, as long as the program doesn't need to obtain more memory from the OS.</li>
<li>Printing to a buffered stream, if the buffer doesn't get flushed during this print call. Likewise, reading from a buffered stream, if enough bytes are available.</li>
</ul>

<p>It would help to demonstrate by showing the system calls made by some programs, e.g. with <code>strace</code> on Linux, with <code>dtruss</code> on macOS or with Systrace under Windows. Compare a program that does a lot of I/O with one that does one big computation and prints the result.</p>

<p>The case of buffered I/O, <a href="https://cseducators.stackexchange.com/users/204/ctrl-alt-delor">suggested by ctrl+alt+delor</a>, is an interesting one because the same library functions may or may not trigger a system call depending on the state of the system.</p>

<p>There is sometimes possible confusion between a <em>library call</em> and a <em>system call</em>. Unix programmers in particular tend to believe that what is documented in section 2 of the manual is system calls, but this is not true on a modern Unix systems. Every function callable from C is a C library function that's a wrapper (possibly very simple, possibly even a macro rather than a function) around a system call that usually, but not always, has the same name and takes more or less the same parameters. You can observe that on a modern Linux/x86_32 system, where many system calls have been upgraded from 32-bit arguments to 64-bit arguments, e.g. <code>strace ls</code> will show calls of <code>getdents64</code> and <code>fstat64</code> rather than <code>getdents</code> and <code>fstat</code>. Under the hood, system calls and library calls have a different calling convention. At the very least, a library call involes a jump/branch instruction while a system call involves a privilege change instruction. Depending on the system, the rules for placing arguments in registers may be different.</p>

<p>You can discuss how a program could make as few system calls as possible by starting from <code>strace /bin/true</code>. Most of its syscalls are due to dynamic linking, so write that one-line program, compile it statically and look at the remaining system calls. Reduce it even further with a more minimalistic libc such as <a href="https://www.fefe.de/dietlibc/" rel="noreferrer">dietlibc</a>.</p>

<pre><code># Install dietlibc, e.g. apt-get install dietlibc-dev on Debian
$ cat a.c
int main(void) {return 0;}
$ diet gcc a.c 
$ strace ./a.out
execve("./a.out", ["./a.out"], [/* 82 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fff98099fe0) = 0
_exit(0)                                = ?
+++ exited with 0 +++
</code></pre>

CC BY-SA 3.0
2017-09-02T09:27:17.890Z
I agree +1, however memory mapped IO could result in an, implicit, system call, if there is a page fault. Where as direct IO uses explicit system calls.  Also `printf` may not make a system call: The C library can buffer the data. The library will call flush if the buffer becomes full. You can also call `flush`. You will notice this sometimes, “Why does `printf` not work / why is output of `printf` delayed?”. On a gnu system (such as Gnu/Linux), as well as `strace`, you are free to look at the source code (though `strace` may be easier/quicker.
ctrl-alt-delor
CC BY-SA 3.0
2017-09-02T10:10:32.673Z
@ctrl-alt-delor As I wrote: “Both of these statements have exceptions”. A page fault is not a system call. (This may be a matter of terminology, but I'll assert it, because I'm a professional OS developer and a “system call” and a “fault handler” are two separate ways to invoke kernel code, and this matches Linux and Windows terminology.) Looking at the source code doesn't tell you which system calls are executed, at most it lets you see the library calls, which as you point out are not directly related (the example of buffered IO is a nice one, thanks).
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-09-02T10:33:51.147Z
@giles [I was not disagreeing with you, just exploring these exceptions] I said implicit system call, I mean here that it triggers a service routine in the kernel. Is it correct that all access to the kernel is through interrupt service routines (hardware interrupts: page fault, device ready; and software interrupts (syscall)?
ctrl-alt-delor
CC BY-SA 3.0
2017-09-02T10:37:51.400Z
@ctrl-alt-delor It's a bit dangerous to take such a general statement as absolute truth because there's usually some bizarre hardware somewhere. But for a sufficiently broad definition of “interrupt service routine” that's true. Depends if you think something like returning from hypervisor mode counts as a software interrupt.
Gilles 'SO- stop being evil'
CC BY-SA 4.0
2023-12-06T20:57:15.423Z
I am still learning the basics, when I see the architecture diagrams online, I always see the System calls in between user space and kernel space, so i find it hard to comprehend how any instruction can be without a sys call ? I mean even if I do a + b , does that not need to access CPU, RAM , Registers and then place the result back in a variable ?
theMyth
CC BY-SA 4.0
2023-12-07T09:37:56.267Z
@theMyth Performing CPU instructions and accessing registers can't involve system calls because system calls work by performing CPU instructions and accessing registers. In theory it would be possible to design a system where accessing memory requires a system call, but it would be very impractical. CPUs with memory separation allow unprivileged code to access a part of memory (based on MMU/MPU/segmentation — look those up). System calls are generally needed to access shared resources, but CPU time+registers are always granted to applications temporarily (time slice in a scheduler).
Gilles 'SO- stop being evil'
CC BY-SA 3.0
2017-09-01T21:49:53.233Z
2017-09-02T10:20:01.393Z
2017-09-02T10:20:01.393Z
Gilles 'SO- stop being evil'
<p>I'm teaching an Operating System course, and was looking for an example of something that <strong>isn't</strong> a system call.</p>

<p>As silly as it may sound, I wasn't able to carve a good example. Everything (accessible to second-year students) that came to my mind involved system call in some way, and looking around for examples didn't help.</p>

<p>So, I'm reaching you: <strong>Is there any good example of operation happening on a computer that does not involve system calls?</strong></p>

<p><em>And wish a long life to that community that I just discovered, but intend to contribute to!</em></p>

<p>Edit: the example can come from any OS, and I know that pretty much <strong>every useful program</strong> requires some system call, that's why I'm asking!</p>

CC BY-SA 3.0
2017-09-01T20:25:51.683Z
Doesn't that depend quite a lot on the OS? Can you be more specific?
Buffy
CC BY-SA 3.0
2017-09-01T20:30:28.803Z
Pretty much any useful program effects the system in some way, whether reading/modifying a file, outputting something to the screen or otherwise.  Even something like `int main(){int i = 0; return 0;}` has to implicitly request resources from the system to store the variable.
IllusiveBrian
CC BY-SA 3.0
2017-09-01T20:34:59.530Z
Maybe an opportunity to talk about layers of abstraction in a system. The deeper you go, the more likely it is you need to talk to the kernel.
Buffy
CC BY-SA 3.0
2017-09-01T20:36:19.167Z
Anyway. Welcome to CSEducators. We try to be helpful, even when we sound a bit gruff.
Buffy
CC BY-SA 3.0
2017-09-02T02:10:56.890Z
The students would probably be familiar with `strlen` and `strcmp`, which are not and do not result in syscalls. Then you have `printf` and `malloc` which are not syscalls, but which may result in syscalls.
that other guy
CC BY-SA 3.0
2017-09-04T11:01:26.803Z
A great example of the misdirection which results from the subjects covered in a syllabus. Almost all code written is userland - i.e. _not_ system calls, yet this question is still not 'trivially obvious'.
Sean Houlihane
<undergraduate><operating-systems>
Good example of what isn't a system call?
# Good example of what isn't a system call?

(Asked by: username_0 on 2017-09-01)

I'm teaching an Operating System course, and was looking for an example of something that **isn't** a system call.

As silly as it may sound, I wasn't able to carve a good example. Everything (accessible to second-year students) that came to my mind involved system call in some way, and looking around for examples didn't help.

So, I'm reaching you: **Is there any good example of operation happening on a computer that does not involve system calls?**

*And wish a long life to that community that I just discovered, but intend to contribute to!*

Edit: the example can come from any OS, and I know that pretty much **every useful program** requires some system call, that's why I'm asking!

**Tags:** undergraduate, operating-systems

> **Comments:**
> **username_1**: Doesn't that depend quite a lot on the OS? Can you be more specific?  
> **username_2**: Pretty much any useful program effects the system in some way, whether reading/modifying a file, outputting something to the screen or otherwise.  Even something like `int main(){int i = 0; return 0;}` has to implicitly request resources from the system to store the variable.  
> **username_1**: Maybe an opportunity to talk about layers of abstraction in a system. The deeper you go, the more likely it is you need to talk to the kernel.  
> **username_1**: Anyway. Welcome to CSEducators. We try to be helpful, even when we sound a bit gruff.  
> **username_3**: The students would probably be familiar with `strlen` and `strcmp`, which are not and do not result in syscalls. Then you have `printf` and `malloc` which are not syscalls, but which may result in syscalls.  
> **username_4**: A great example of the misdirection which results from the subjects covered in a syllabus. Almost all code written is userland - i.e. _not_ system calls, yet this question is still not 'trivially obvious'.  

---

## 1 answers

### Answer by username_5 on 2017-09-01. Score: 14

The simple breakdown is:

Anything that performs input/output involes a series of system calls.
Anything that's purely computational doesn't involve system calls.

Both of these statements have exceptions (I/O through memory-mapped files or peripherals is I/O without syscalls, calling a hardware accelerator or allocating memory is syscalls without externally visible I/O) but they're a good approximation.
So here are some examples of operations that don't involve system calls:

Getting or changing the value of a variable.
Arithmetic operations on integers and floats.
Conditionals and loops whose body doesn't involve system calls.
Operations on strings such as searching, joining, splitting, etc.
Manipulations of data structures such as lists, arrays, matrices, trees, etc.
Memory management, as long as the program doesn't need to obtain more memory from the OS.
Printing to a buffered stream, if the buffer doesn't get flushed during this print call. Likewise, reading from a buffered stream, if enough bytes are available.

It would help to demonstrate by showing the system calls made by some programs, e.g. with strace on Linux, with dtruss on macOS or with Systrace under Windows. Compare a program that does a lot of I/O with one that does one big computation and prints the result.
The case of buffered I/O, suggested by ctrl+alt+delor, is an interesting one because the same library functions may or may not trigger a system call depending on the state of the system.
There is sometimes possible confusion between a library call and a system call. Unix programmers in particular tend to believe that what is documented in section 2 of the manual is system calls, but this is not true on a modern Unix systems. Every function callable from C is a C library function that's a wrapper (possibly very simple, possibly even a macro rather than a function) around a system call that usually, but not always, has the same name and takes more or less the same parameters. You can observe that on a modern Linux/x86_32 system, where many system calls have been upgraded from 32-bit arguments to 64-bit arguments, e.g. strace ls will show calls of getdents64 and fstat64 rather than getdents and fstat. Under the hood, system calls and library calls have a different calling convention. At the very least, a library call involes a jump/branch instruction while a system call involves a privilege change instruction. Depending on the system, the rules for placing arguments in registers may be different.
You can discuss how a program could make as few system calls as possible by starting from strace /bin/true. Most of its syscalls are due to dynamic linking, so write that one-line program, compile it statically and look at the remaining system calls. Reduce it even further with a more minimalistic libc such as dietlibc.
# Install dietlibc, e.g. apt-get install dietlibc-dev on Debian
$ cat a.c
int main(void) {return 0;}
$ diet gcc a.c 
$ strace ./a.out
execve("./a.out", ["./a.out"], [/* 82 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fff98099fe0) = 0
_exit(0)                                = ?
+++ exited with 0 +++

> **Comments:**
> **username_6**: I agree +1, however memory mapped IO could result in an, implicit, system call, if there is a page fault. Where as direct IO uses explicit system calls.  Also `printf` may not make a system call: The C library can buffer the data. The library will call flush if the buffer becomes full. You can also call `flush`. You will notice this sometimes, “Why does `printf` not work / why is output of `printf` delayed?”. On a gnu system (such as Gnu/Linux), as well as `strace`, you are free to look at the source code (though `strace` may be easier/quicker.  
> **username_5**: @username_6 As I wrote: “Both of these statements have exceptions”. A page fault is not a system call. (This may be a matter of terminology, but I'll assert it, because I'm a professional OS developer and a “system call” and a “fault handler” are two separate ways to invoke kernel code, and this matches Linux and Windows terminology.) Looking at the source code doesn't tell you which system calls are executed, at most it lets you see the library calls, which as you point out are not directly related (the example of buffered IO is a nice one, thanks).  
> **username_6**: @giles [I was not disagreeing with you, just exploring these exceptions] I said implicit system call, I mean here that it triggers a service routine in the kernel. Is it correct that all access to the kernel is through interrupt service routines (hardware interrupts: page fault, device ready; and software interrupts (syscall)?  
> **username_5**: @username_6 It's a bit dangerous to take such a general statement as absolute truth because there's usually some bizarre hardware somewhere. But for a sufficiently broad definition of “interrupt service routine” that's true. Depends if you think something like returning from hypervisor mode counts as a software interrupt.  
> **username_7**: I am still learning the basics, when I see the architecture diagrams online, I always see the System calls in between user space and kernel space, so i find it hard to comprehend how any instruction can be without a sys call ? I mean even if I do a + b , does that not need to access CPU, RAM , Registers and then place the result back in a variable ?  
> **username_5**: @username_7 Performing CPU instructions and accessing registers can't involve system calls because system calls work by performing CPU instructions and accessing registers. In theory it would be possible to design a system where accessing memory requires a system call, but it would be very impractical. CPUs with memory separation allow unprivileged code to access a part of memory (based on MMU/MPU/segmentation — look those up). System calls are generally needed to access shared resources, but CPU time+registers are always granted to applications temporarily (time slice in a scheduler).  

---

