1)
System calls
differ from platform to platform. By using a
stable API
, it is easier to migrate your software to different platforms.
2) The operating system may provide newer versions of a system call with enhanced features. The API implementation will typically also be upgraded to provide this support, so if you call the API, you'll get it. If you make the system call directly, you won't. (For example, code that called the Linux pthreads API for mutexes got the benefit of futexes without adding a single line of code. Had you called the system directly, that would not have happened.)
3) The API usually provides more useful functionality than the system call directly. If you make the system call directly, you'll typically have to replicate the pre-call and post-call code that's already implemented by the API. (For example the 'fork' API includes tons of code beyond just making the 'fork' system call. So does 'select'.)
2) The operating system may provide newer versions of a system call with enhanced features. The API implementation will typically also be upgraded to provide this support, so if you call the API, you'll get it. If you make the system call directly, you won't. (For example, code that called the Linux pthreads API for mutexes got the benefit of futexes without adding a single line of code. Had you called the system directly, that would not have happened.)
3) The API usually provides more useful functionality than the system call directly. If you make the system call directly, you'll typically have to replicate the pre-call and post-call code that's already implemented by the API. (For example the 'fork' API includes tons of code beyond just making the 'fork' system call. So does 'select'.)
4) The API can support multiple versions of the operating system and detect which version it needs to use at run time. If you call the system directly, you either need to replicate this code or you can only support limited versions.