c) I concluded from this that that I should libc instead as a system
interface, and that it would be just as stable (if not more so)
since Apple is a commercial company
The fact that even this interface may not remain backward compatible
is disappointing however. When I first learned about the concept of
frameworks, I (naively) assumed this meant that breaking backwards
library compatibility would no longer be required, since you could
just bump the compatibility version so all older programs could
transparently keep using the older version of the framework.
Obviously, for something like libSystem this is not a solution "for
free" since you'd still have to keep patching the old version to
keep running on the new syscall interfaces if older syscalls are
removed/changed.
Actually, it seems I misread the comments about vfork being
deprecated, as the man page states:
This system call will be eliminated when proper system sharing
mechanisms
are implemented. Users should not depend on the memory sharing
semantics
of vfork as it will, in that case, be made synonymous to fork.
So as long the symbol remains exported from libSystem (synonymous to
fork at some point or not), it doesn't matter to me (from a backwards
binary compatibility standpoint).
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
