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?

  • 8
    If it ain't broke, don't fix it. – James McLeod Feb 20 '16 at 3:27
  • Since when are these syscalls? here is the synopsis for a syscall(): #define _GNU_SOURCE /* See feature_test_macros(7) / #include <unistd.h> #include <sys/syscall.h> / 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 6:44
  • @user3629249: they are listed in syscalls(2) 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 7: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 7:20
  • How do you think fopen works? – Erik Eidt Feb 20 '16 at 14:45

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.