I think the overall sentiment is right on, but I'm not sure I get the last question. posix is a superset, yes, but it doesn't provide replacements for the C library. Perhaps better phrased as "Why limit yourself to only standard C?"?
Since version 2.3.3, rather than invoking the kernel's fork() system call, the glibc fork() wrapper that is provided as part of the NPTL threading implementation invokes clone(2) with flags that provide the same effect as the traditional system call. The glibc wrapper invokes any fork handlers that have been established using pthread_atfork(3).
At least on my ubuntu box.
andrew-think ⚑ ~ strace -f sh -c 'sh &' 2>&1 | egrep -A1 'clone|fork'
clone(Process 2646 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7ff002bac9d0) = 2646POSIX itself doesn't even use the words system call, only function, to describe them.
What makes Linux as an operating system conform to POSIX is the API, implemented in C. In this API, the function fork() has to do what the POSIX specification states. As stated, this fork() does not even use the system call fork in the resent versions of glibc.
As POSIX is a superset of the C standard library, it does provide a replacement. The C standard library exists to provide the very basic functionality in it, in environments and operating systems that are not POSIX compliant.
C standard library is part of the C implementation. The POSIX API, implemented in what ever language, is part of the operating system.
That looks to be some questionable phrasing from the article.
Yes, fork() is a system call on many platforms, but not on all.
And fork() is not ubiquitous. If anything, it's one of the common and can be one of the more intractable sources of porting problems within C code.
fork() does rather more than many C programmers might realize. About 5 or 10% of the calls I've encountered in the many C applications I've ported will use fork() for most or all of what it can do. The remaining calls throw that context away, and can often be equally or better served with vfork()/exec() or some other C call.
Those applications that use fork() for what it can do can be and usually are more difficult to port to the various platforms that lack copy-on-read virtual memory.
Every single major operating system except one has fork. Colour me not very concerned.
The standard C library and the POSIX API are two quite different things.
The standard C library is a library of functions defined by the various C language standards. These functions should be available on any C language implementation regardless of the platform (Unix/POSIX, Windows, embedded RTOS, micro-controller with no OS, etc.).
The POSIX API is a platform specification for Unix like platforms (though the API is sometimes available non-natively on non-Unix like platforms). It is comparable to the win32 API on windows. It has no particular connection to the C language other than that C is the language in which the API is provided.
Perhaps one reason for this confusion is that today many people are familiar with higher level programming environments like Java or Python which provide much richer standard libraries than do C and C++. They include things like multithreading and network communications. C programmers need to use platform specific API's like POSIX or win32 to access these services. Also note that pretty much any higher level language running on a modern OS is ultimately using the platform system API's to provide such services because the OS kernel doesn't allow user space programs access to them other than through a system call mechanism (which the platform API's typically wrap).
One other possible source of confusion that the post doesn't mention is that on Unix the library one links to for both the C standard library functions and the Unix/POSIX system API's is called libc (it's usually called glibc on Linux). Despite the name this is not the same thing as the C standard library.
I've never seen the One True Explanation of this anywhere, probably because it's something that Linux/BSD/POSIX/whatever people learn on day 1. The question seems to be strangely un-Googleable.
Section 3 is for library API's. It typically includes the C standard library functions in addition to pages for other libraries which are installed on the system.
If you look at your examples you will find that fputs and fseek are declared in stdio.h, which is a C standard library header whereas lseek is declared in unistd.h which is a Unix/POSIX header.
lseek is a low level call to the kernel's filesystem interface. You can't access a file more directly unless you write a kernel module or modify the kernel. fseek and fputs wrap the low-level filesystem interface in a stream abstraction.
Also fseek and fputs should be available on any platform with a C compiler (including Windows) whereas lseek is only normally available on Unix/POSIX platforms.
Another one is zlib, and lots of more.
As an example that went in the other direction: The Common Lisp language specification! It even has host, path, version number for describing file names - but I think this now hampers the language's image if one stars coding in it for the first time.