site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com With the usual disclaimer about system calls, where is creat? In sys/syscall.h #define SYS_wait4 7 /* 8 old creat */ #define SYS_link 9 -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Jan 9, 2009, at 10:22 AM, Joel Reymont wrote: I could not find it in the header file. That's because it only exists as a library wrapper in Libc/compat-43/ FreeBSD/creat.c Calling system calls directly is reckless and will impair binary compatibility. In particular, the system call interfaces are not the interfaces which are documented in section 2 of the manual pages. At some point, we will likely go through and compact the system call table, which will end up renumbering everything on you and anyone else using syscall(2) or direct traps in order to make calls directly without library interposition. The interfaces documented in section 2 of the manual pages are the system interfaces at the top of Libc. For example, here is the Libc implementation of kill(2), as of Leopard (and maybe Tiger): /* * kill stub, which wraps a modified kill system call that takes a posix * behaviour indicator as the third parameter to indicate whether or not * conformance to standards is needed. We use a trailing parameter in * case the call is called directly via syscall(), since for most uses, * it won't matter to the caller. */ int kill(pid_t pid, int sig) { #if __DARWIN_UNIX03 return(__kill(pid, sig, 1)); #else /* !__DARWIN_UNIX03 */ return(__kill(pid, sig, 0)); #endif /* !__DARWIN_UNIX03 */ } Notice the "most uses": the POSIX parameter ends up being whatever garbage happens to be in the register at the time of the call (most probably, non-0 and therefore POSIX behavior; hope you don't depend on historical MacOS X behaviour). This was considered acceptable risk, due to most code that would care or use the interface being ported code, and properly trapping the signals they send to their own process groups, so whether or not sending a signal to the process group signals themselves or not won't matter (which is the specific POSIX behavioural change that necessitated adding the parameter). Things like socket(2)/recvmsg(2)/accept(2)/etc. and other network- related calls are even worse, as they need to translate error codes on return. PS: I'm also still not seeing why you don't want to be able to link your compiler's output with third party supplied libraries. This email sent to site_archiver@lists.apple.com