4 ms·
So, 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
by CamperBob 16y ago
So, 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.