I do not wish to be a troll but most of the information in that post is plain wrong. For one fork() is indeed a system call. If you want a good understanding of the true essence of POSIX (UNIX API) I recommend reading: Advanced Programming in the UNIX Environment.
If everything in Unix development is POSIX, what the hell does C library do?
11–20 of 24 posts
Re: If everything in Unix development is POSIX, what the hell does C library do?
#12There'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.
Re: If everything in Unix development is POSIX, what the hell does C library do?
#13One example of good restriction to the "C" library is the lua reference implementation - because of that it can compile for lots of platforms (well 32-bit and above) without a problem. Another one is zlib, and lots of more.
As a result there are features missing that you might find in other implementations, e.g. standard Lua has IO but cannot create directories. But getting halfway there on all platforms is better than all the way on one platform and making you work out how to fix it to run on yours.
Re: If everything in Unix development is POSIX, what the hell does C library do?
#14Not sure where you got the idea that fork() isn't a system call. It certainly is on my computer. 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?"?
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.
Re: If everything in Unix development is POSIX, what the hell does C library do?
#15Not sure where you got the idea that fork() isn't a system call. It certainly is on my computer. 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?"?
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 encou…
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.
Re: If everything in Unix development is POSIX, what the hell does C library do?
#16I do not wish to be a troll but most of the information in that post is plain wrong. For one fork() is indeed a system call. If you want a good understanding of the true essence of POSIX (UNIX API) I recommend reading: Advanced Programming in the UNIX Environment.
Maybe you wish to elaborate on what else is wrong with the article, other than a nitpick on what the author admitted was a spur of the moment?
Re: If everything in Unix development is POSIX, what the hell does C library do?
#17One example of good restriction to the "C" library is the lua reference implementation - because of that it can compile for lots of platforms (well 32-bit and above) without a problem. Another one is zlib, and lots of more.
As a result there are features missing that you might find in other implementations, e.g. standard Lua has IO but cannot create directories. But getting halfway there on all platforms is better than all the way on one platform and making you work out how to fix it to run on yours.
Yes, I agree, but back in the Apple ][ DOS era (before Pro-DOS) there were even not directories.
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.
Re: If everything in Unix development is POSIX, what the hell does C library do?
#18There'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…
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 )? 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.
Re: If everything in Unix development is POSIX, what the hell does C library do?
#19There'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…
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 )? 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/B…
Those 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
Re: If everything in Unix development is POSIX, what the hell does C library do?
#20There'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…
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 )? 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/B…
[deleted]