Using syscalls to read files - is this bad?

Question

I have some (presumably stable) legacy C code that uses POSIX system calls to read binary files. It's nothing more than creat(), read(), and write(). The program doesn't sit close to the metal at all (it loads string data into memory), so it seems wrong that it's using syscalls. I think I can refactor it easily to use more standard functions.

But, given that my code doesn't need to be portable, I can't think of a good reason to rewrite it. Am I missing something, or should I leave the code be?

Since when are these `syscalls`? here is the synopsis for a `syscall()`: #define _GNU_SOURCE /* See feature_test_macros(7) */ #include #include /* For SYS_xxx definitions */ int syscall(int number, ...); Note: the `...` is a variable list of parameters for the called function — user3629249, Feb 20 '16 at 06:44
@user3629249: they *are* listed *in* [syscalls(2)](http://man7.org/linux/man-pages/man2/syscalls.2.html) so the OP is right in calling them system calls (at least on Linux; AFAIK POSIX don't speak of system calls) — Basile Starynkevitch, Feb 20 '16 at 07:19
@William: why do you think it is wrong to use syscalls? It is often the right thing to do... — Basile Starynkevitch, Feb 20 '16 at 07:20

score 6 · Accepted Answer · answered Feb 20 '16 at 09:27

Yes, of-course you must get rid of those terrible low-level syscalls. And while you are at it, you should also get rid of that terrible low-level language called C.
<sarcasm off>

On a more serious note and based on the principle of YAGNI, unless you have a clear need to change your use of syscalls to something else, doing it is only a waste of effort.

The primary reason for not using those syscalls is because you would need portability to non-posix systems, but you already stated that that is not the case for you.

Using syscalls to read files - is this bad?

1 Answers1