Hacker News Reader

Comment by waitwhat | Hacker News Reader

On Linux, there's typically both an open(3) and an open(2). The former is implemented by glibc and calls the latter which is implemented by the kernel.

So an app calls the open() function. This results in an unresolved symbol which the run-time linker matches up with the open() exported by glibc. glibc then does the open() syscall.

View on HN

open(2) is the wrapper within the libc. There is no open(3) on Linux.

Section 2 of the unix manual is for syscalls. Section 3 is for C library functions. http://en.wikipedia.org/wiki/Man_page#Manual_sections

If libc implements it, then it is by definition in section 3.

EDIT: (signing out of this sub-thread)

Sorry, you're just wrong.

Have you ever called a system call by hand using assembly?

Have you ever looked at glibc's source?

Habe you ever looked at the kernel's close() syscall?

syscall number 5 you mean?

libc implements a function called open. Its documentation appears in section 3 of the UNIX manual. Because of that, we call it open(3). Linux implements a system call called open. Its documentation appears in section 2 of the UNIX manual. Because of that, we call it open(2). From assembly, you manually call open(2). From a C program linked against libc, you typically open(3). open(3) can be hooked, because it's just a regular function. open(2) is not a function, and so cannot be hooked like a function.

Reply on news.ycombinator.com