There are seveveral reasons for an _ prefix.
The main reason in source code is to distinguish the ANSI/ISO C name space from the implementation namespace. So if I have 'size_t', it the ANSI/ISO C name space, but if I have __darwin_size_t, it's implementation namespace.
The second is to distinguish 'soft' vs. 'hard' symbols in a multilevel symbolic namespace. If you are a Python fan, think of it as indenting. I can have _foo, which is a strong symbol, and __foo, a weak symbol, and then associate them. You can break this association be providing a _foo of your own to override the weak association to __foo. This is basically how mallocdebug works.
The third is a convention between assembly scoping and C scoping (technically, also a namespace issue), where assembly things have no _ and C things do.
OK, that out of the way, _posix_spawn is the system call trap for posix_spawn the wrapper function. The wrapper function wraps up the parameters into a descriptor structure, then traps to the system call __posix_spawn with the descriptor as a parameter.
The design of Mac OS X is such that the descriptor structure - representing a contract between user and kernel space - is allowed to change from release to release, or even on each software update, as long as the libc/libSystem and the kernel agree to the same contract.
Basically, the system call interface is defined as living at the top of libc, not at the actual user/kernel boundary.
If you are implementing a runtime for a Forth interpreter, or working on Googles Go language, etc., you have to buy into dyld and everything else to keep from breaking between releases.
In a shorter sentence: leave __posix_spawn alone.
-- Terry On May 1, 2010, at 1:32 PM, Ariel Feinerman < email@hidden> wrote: 2010/4/23 Jean-Daniel Dupas <email@hidden>Le 22 avr. 2010 à 23:16, Ariel Feinerman a écrit :
> Hi,
>
> I look at libc`s posix_spawn() function, one calls __posix_spawn() internally, I think __posix_spawn() is system call, but I learn xnu source by grep carefully, threre is only one function: posix_spawn(). What is __ ?
nm libSystem.dylib
0000000000048020 t ___posix_spawn
Answer: a libSystem internal symbol (aka implementation detail). What are you trying to do ?
Nothing, I want to look at __posix_spawn() source when I learn libc implementation. So does it means __posix_spawn() prototype in libc is posix_spawn() prototype in xnu?
For example if I want to call function from kernel or implement wrapper I need to insert __ ?
|