If everything in Unix development is POSIX, what the hell does C library do? • Hacker News Board

Re: If everything in Unix development is POSIX, what the hell does C library do?

#21

Post by tgflynn » Sun, Jan 02, 2011, 11:08 PM UTC

CamperBob wrote: post #18

tgflynn wrote: post #12

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…

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…

Section 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.

Re: If everything in Unix development is POSIX, what the hell does C library do?

#22

Post by seabee » Sun, Jan 02, 2011, 11:54 PM UTC

malkia wrote: post #17

seabee wrote: post #13

Earlier quoted context omitted.

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.

Certainly, but you don't have to go as far back as that for an example: just compare the drive letters in Windows to the lack of them in Unix.

It works very well in Lua's favour to stick to just the C library given the desire to use it in embedded computers. However, it's valid to wonder why a basic feature supported by 99% of computers is not available out of the box; you judge things based on what's available now, not the past. I should think the C library would be quite different had it been designed 20 years later.

Re: If everything in Unix development is POSIX, what the hell does C library do?

#23

Post by bdonlan » Mon, Jan 03, 2011, 1:30 AM UTC

jdefr89 wrote: post #11

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.

The definition of exactly what is a system call and what is not varies by platform. For example, some OSes may implement sleep() as a system call; others may implement it using nanosleep() or even alarm() and sigwait(). Even fork() has been implemented as a library function, eg in cygwin. What method is used to implement low-level library functions like this should be considered an implementation detail.

Re: If everything in Unix development is POSIX, what the hell does C library do?

#24

Post by bdonlan » Mon, Jan 03, 2011, 1:32 AM UTC

CamperBob wrote: post #18

tgflynn wrote: post #12

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…

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…

Although 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.