I caught the same thing, but learned something interesting while double checking I wasn't crazy (from man 2 fork):

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) = 2646

Ah, but just because glibc doesn't call the fork() system call doesn't mean the kernel doesn't have one. :) I bet you could still get to by calling something like __glibc_old_fork(), or at the very least a manual syscall(SYS_FORK) should work.

POSIX itself doesn't even use the words system call, only function, to describe them.

Yep:

  $ grep fork /usr/include/asm/unistd_64.h     
  #define __NR_fork				57
  __SYSCALL(__NR_fork, stub_fork)
  #define __NR_vfork				58
  __SYSCALL(__NR_vfork, stub_vfork)
  
  $ strace -f ruby -e 'syscall 57' 2>&1 | egrep 'fork|clone'
  fork(Process 4138 attached (waiting for parent)

  $ strace -f ruby -e 'fork' 2>&1 | egrep 'fork|clone'
  execve("/home/andrew/.rvm/rubies/ree-1.8.7-2010.02/bin/ruby", ["ruby", "-e", "fork"], [/* 47 vars */]) = 0
  clone(Process 4145 attached

It so happens, that Linux kernel has a system call named fork. But nothing states that this system call has to conform to the POSIX specification of fork(). If it does so, it does so for convenience.

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.

Ah, fork(). One of my favorite C calls. Not.

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.

vfork is probably worse because you have to be very careful if exec fails. Calling a function to log the error is likely to mess up the parent's memory.

vforks restrictions mean that in most cases where fork is used in unix development besides the trivial fork/exec combination it won't be the proper choice.

Every single major operating system except one has fork. Colour me not very concerned.

thanks for correcting me on fork(); not sure what I was thinking when I wrote that statement :)

Well, I guess I should have waited for this discussion to reach a conclusion :) I read in Advanced Linux Programming (the famous ALP book) that fork() as well as creating threads via pthread library use clone() in the background. Any ways, the discussion here is quite informative!