Re: creat system call?
Re: creat system call?
- Subject: Re: creat system call?
- From: Terry Lambert <email@hidden>
- Date: Fri, 9 Jan 2009 12:26:55 -0800
On Jan 9, 2009, at 10:22 AM, Joel Reymont wrote:
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
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden