3 ms·
There's something a bit strange about the approach of this post that suggests a confusion of concepts (though I'm not saying there's anything factually incorrec
by tgflynn 16y ago
There's something a bit strange about the approach of this post that suggests a confusion of concepts (though I'm not saying there's anything factually incorrect about it).
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.
- CamperBob 16y agoSo, here's a question I have as a Win32 developer, which may tie in with the whole what-is-POSIX topic. What does the API documentation mean when it refers to C calls like "fputs(3)" or "lseek(2)" (as in the example here: http://linux.die.net/man/3/fseek http://linux.die.net/man/3/fseek )? How are these different from 'normal' fputs() and lseek()? 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.
- daxelrod 16y agoThose are Unix manpage section numbers. fseek(3) means fseek in section 3 of the manpages. This can help to differentiate between a command line program and C function of the same name, for example. See http://www.december.com/unix/ref/mansec.html http://www.december.com/unix/ref/mansec.html
- deleted 16y ago[deleted]
- tgflynn 16y agoSection 2 is for system calls. In other words libc functions which are just thin wrappers around the system call interface provided by the kernel. 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.
- bdonlan 16y agoAlthough others have explained things a bit, I'll try making an analogy to win32: Section 2 ("system calls") contains functions which are traditionally serviced directly by the kernel. In win32, this would mean that they (historically) correspond more-or-less directly to a Nt*() function in ntdll (or a kernel entry point). Section 3 ("library functions") are all other library functions, including ones serviced by third-party libraries.