November 2008 - Darwin-dev - lists.apple.com

[ANN]Yet another CFLite
by Jean-Daniel Dupas 23 Nov '08

23 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hello, http://code.google.com/p/cf-lite _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I'm not the author of this project, but it may interest everybody that would like to use CF based application on other plateforms (It already compile fine on Windows). « This project attempts to consolidate the work of anyone interested in using the Apple Core Foundation libraries outside of the Mac OS X environment. This project builds on the various open source releases of CFLite, as well as work from the DarwinBuild, PureDarwin, and other locations The hope is that this will become a central source for Core Foundation work outside of the Macintosh, and that there will be free transmission of patches back upstream.» This email sent to site_archiver(a)lists.apple.com

1 0

Re: Meaning of @OSF_COPYRIGHT@
by Jonas Maebe 22 Nov '08

22 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 22 Nov 2008, at 23:43, Jonas Maebe wrote: Then, in bsd/dev/ppc/unix_signal.c you have in sigreturn(): Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… mask = sigmask(SIGFPE); if (((ut->uu_sigmask & mask) == 0) && (p->p_sigcatch & mask) && ((p->p_sigignore & mask) == 0)) { action = ps->ps_sigact[SIGFPE]; if((action != SIG_DFL) && (action != SIG_IGN)) { thread_enable_fpe(th_act, 1); } } I.e., only here fpu exceptions are enabled again. siglongjmp() does not go through sigreturn(), and hence does not re-enable fpu exceptions. Looking further, it turns out that you can solve it by reinstalling the SIGFPE signal handler after the signal occurred (see the thread_enable_fpe calls in in setsigvec() in bsd/kern/kern_sig.c). That also works fine now at least (under 10.5.5), but I seem to remember that back in the days, if I did that I'd immediately get the same exception again. Although that might have been with a homebrewn setjmp rather than with sigsetjmp... This email sent to site_archiver(a)lists.apple.com

1 0

Re: Meaning of @OSF_COPYRIGHT@
by Jonas Maebe 22 Nov '08

22 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 22 Nov 2008, at 21:39, Terry Lambert wrote: In bsd/kern/kern_sig.c, there is this code in postsig() (xnu-1228.7.58): #ifdef __ppc__ /* Needs to disable to run in user mode */ if (signum == SIGFPE) { thread_enable_fpe(current_thread(), 0); } #endif /* __ppc__ */ Then, in bsd/dev/ppc/unix_signal.c you have in sigreturn(): Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Nov 22, 2008, at 11:56 AM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: My initial version used some form of (sig)longjmp instead of steps 5 to 7 to hand over control to our run time system, but that does not work for fpu exceptions (at least not on PPC). The reason was that as long as you did not return from a signal handler, fpu exceptions remained disabled (well, you could re-enable them in the fpscr, but the kernel dropped them on floor as soon as they occurred again afterwards). I can't immediately find again where this happens in xnu, but if you are interested I could try to look it up again. Please do; that was the specific intent of sigsetjmp/siglongjmp. It appears to be ppc-specific (back when I first checked this code, there was no talk yet of Intel Macs and hence no "#ifdef ppc" either). The code is in bsd/kern/kern_sig.c and bsd/dev/ppc/unix_signal.c The reason is that if you don't do this, the fpu exception will be trigger again as soon as you enter the signal handler. Although I'm not sure anymore why simply cleaning out fpscr wouldn't work (after all, the fpscr at exception time is available via the signal context, and the "high level" exception info is available via the siginfo_t* parameter). mask = sigmask(SIGFPE); if (((ut->uu_sigmask & mask) == 0) && (p->p_sigcatch & mask) && ((p->p_sigignore & mask) == 0)) { action = ps->ps_sigact[SIGFPE]; if((action != SIG_DFL) && (action != SIG_IGN)) { thread_enable_fpe(th_act, 1); } } I.e., only here fpu exceptions are enabled again. siglongjmp() does not go through sigreturn(), and hence does not re-enable fpu exceptions. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Meaning of @OSF_COPYRIGHT@
by Jonas Maebe 22 Nov '08

22 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 22 Nov 2008, at 22:17, Conrad G T Yoder wrote: Your best best is to speak to an independent attorney who is familiar with software law. Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… As has been mentioned, you are not going to get sound legal advice on a technical list. If you contact Apple's legal team/DTS, you are going to get legal advice that is in Apple's best interest, which may or may not be helpful for your situation. The problem is that I'm not getting any advice whatsoever from them (which is why I sent this question to this list). I don't mind getting a "no" (I'd prefer a "yes" to a "no", but also a "no" to no answer). I just want to know where I stand and to what extent it is worth to spend my time on Mac OS X/iPhone support (such as figuring out a way to run our 4600+ regression tests on that thing without the ability to remotely login). The problem is not really software law. APIs have been ruled as uncopyrighteable in the past (http://www.eetimes.com/news/design/showArticle.jhtml?articleID=201801579 ). Since this header is however distributed as part of the iPhone SDK, it's obviously subject to the terms of the iPhone SDK agreement (which I accepted when I downloaded it). And that's basically a contract, and that contract says that you cannot distribute derivative works based on the SDK, except where the files are licensed under an open source/ free software license which does allow it (although I'm not sure whether I'm even allowed to say this, because the contents of the original NDA itself were also under NDA; I haven't checked whether this condition was lifted together with the NDA on info in published releases of the SDK). But even if my hypothetical independent attorney could interpret that agreement as allowing the distribution of a derivate of that header, then if Apple's lawyers disagreed it would help me nothing (since I sure as hell am not prepared for nor interested in a court battle with Apple's legal department). An independent lawyer could at best tell me whether there is a high or low chance whether Apple's lawyer would agree with one or other interpretation. Which is not a great deal when you consider that I do all this work for free. The kicker is of course that in practice, Apple's legal department probably couldn't care less about what I actually do in this case (and all this whining will probably at most expedite a negative answer). That's of course logical in a sense, as it's not like my work will make or break Apple in any way; commercially, it only influences a number of smaller Mac companies with (often legacy) Pascal code, and some others that are porting Delphi/Win32 apps to Mac OS X. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Meaning of @OSF_COPYRIGHT@
by Conrad G T Yoder 22 Nov '08

22 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AclM575D3Sqrz6247kW4wGrEm0emYA== Thread-topic: Meaning of @OSF_COPYRIGHT@ User-agent: Microsoft-Entourage/12.14.0.081024 At 11/22/08 2:56 PM -0500, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: > > Not distributing anything at all (or worse, distributing a file that > may make me and them liable for copyright infringement lawsuits by > Apple) is obviously even less user-friendly, hence my question to see > what my options are. As has been mentioned, you are not going to get sound legal advice on a technical list. If you contact Apple's legal team/DTS, you are going to get legal advice that is in Apple's best interest, which may or may not be helpful for your situation. Your best best is to speak to an independent attorney who is familiar with software law. -Conrad -- Happiness - We're all in it together! _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com smime.p7s

1 0

Re: what does FAILED TO GET ASN FROM CORESERVICES mean?
by Bill Janssen 22 Nov '08

22 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks, Shawn. Looks like this question should go to cocoa-dev. I'm amazed that a system daemon can get access to the window server *at any time*, yet this setup seems to work most of the time. So I'm puzzled at what's going on here, IPC-wise. Bil Shawn Erickson <shawnce(a)gmail.com> wrote: > On Thu, Nov 20, 2008 at 7:48 PM, Bill Janssen <janssen(a)parc.com> wrote: > > I'm running a daemon, started by SystemStarter at boot time, and > > running as me (an admin account), which periodically invokes > > OpenOffice's "soffice" binary to convert MS Office docs to PDF. Works > > most of the time, but sometimes OpenOffice crashes with this error > > message: > > Likely failing to get a connection to the window server... anything > listed in the console log when it crashes out? > > The crash log appears to live under /Library so this application isn't > being truly run as a particular user, at least not in the way it > normally would. As a result I think all bets are off having it work > consistently ... depending on how it was coded / what frameworks it > depends on. > > You really should use a launch agent to launch this type of thing in a > users aqua session and not a daemon. Daemons live in the root session > and don't have reliable access to the window server and this software > appears to require such a connection, it is using AppKit for example. > > -Shawn _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Meaning of @OSF_COPYRIGHT@
by Jonas Maebe 22 Nov '08

22 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 22 Nov 2008, at 21:39, Terry Lambert wrote: Ok, I'll have a look. #include <signal.h> #include <stdio.h> #include <ucontext.h> #include <setjmp.h> // check whether we really caught the exception static int caught; static sigjmp_buf env; typedef void (*__sighandler_t)(); void install_signal_handler(int signo, __sighandler_t handler) { struct sigaction sa; sa.sa_handler = (void *)handler; sigemptyset(&sa.sa_mask); // needed for the ucontext parameter to be available sa.sa_flags = SA_SIGINFO; sigaction(signo, &sa, NULL); } int main() { double a, b; b = 0.0; asm volatile("mtfsfi 6,15"); // install the handler for SIGFPE install_signal_handler(SIGFPE, signal_handler); // trigger an exception caught = 0; if (!sigsetjmp(env,1)) { a = b/b; printf("Should never get here\n"); return 1; } else { printf("Returning from longjmp 1, caught signal: %d\n",caught); } if (!caught) return 1; return 0; } The output is (on a dual G5): $ gcc -o sig6 sig6.c $ ./sig6 Returning from longjmp 1, caught signal: 1 Should never get here $ sw_vers ProductName: Mac OS X ProductVersion: 10.5.5 BuildVersion: 9F33 Thanks, Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Nov 22, 2008, at 11:56 AM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: [ ... ] @OSF_COPYRIGHT@ The base intent of strings of this format in source code us to cause source code control systems to insert/replace the text with source code known to the sccs at check-in time. Given that our current sccs checkin scripts do not reprocess a number of tag string like $Id:$ and this one, it would be my completely unofficial guess that the copyright boiler-plate for the file was copied from the corresponding x86 file, and that was left in accidently (_struct.h in x86 and ppc are new works by Ed, myself, and others as part of cleaning up namespace issues for UNIX conformance). Ok, thanks. I guess I'll have to go for installation time conversion in that case (unless sw licensing one day decides otherwise)... The official Apple position is a question best directed to DTS. I wish they (well, sw licensing) were as responsive and helpful as you are. My initial version used some form of (sig)longjmp instead of steps 5 to 7 to hand over control to our run time system, but that does not work for fpu exceptions (at least not on PPC). The reason was that as long as you did not return from a signal handler, fpu exceptions remained disabled (well, you could re-enable them in the fpscr, but the kernel dropped them on floor as soon as they occurred again afterwards). I can't immediately find again where this happens in xnu, but if you are interested I could try to look it up again. Please do; that was the specific intent of sigsetjmp/siglongjmp. Assuming the sigsetjmp happened prior to the signal handler, I would expect the mask state to be restored on siglongjmp. If it is not, I'd class that as a bug (NOTE: not a bug if you are using {set| long}jmp instead of sig{set|long}jmp). If you don't see this, please file a bug. Before I do so, here's a test program from 2004 I dug up that demonstrates the problem (ppc-specific) -- just to make sure that I didn't overlook anything: void signal_handler(int signum, siginfo_t *info, ucontext_t* sigcontext) { caught = 1; siglongjmp(env,1); } // trigger another exception caught = 0; if (!sigsetjmp(env,1)) { a = b/b; printf("Should never get here\n"); return 1; } else { printf("Returning from longjmp 2, caught another signal: %d \n",caught); } if (!caught) return 1; I'm not sure what alternatives I have to convert hardware/OS exceptions into language exceptions (at least not if I want to be able to provide backtraces to the consumers of those exceptions, like we do right now. You could always take and eat the Mach exception sent to your task, prior to it being converted into an AST and then into a signal. I admit I took the easy road until now and simply started off from a copy of the FreeBSD exception handling code we already have. Maybe I'll have to dig in Mach after all (until now I've been able to avoid that :) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Meaning of @OSF_COPYRIGHT@
by Terry Lambert 22 Nov '08

22 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com The official Apple position is a question best directed to DTS. Please do; that was the specific intent of sigsetjmp/siglongjmp. If you don't see this, please file a bug. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Nov 22, 2008, at 11:56 AM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: [ ... ] @OSF_COPYRIGHT@ The base intent of strings of this format in source code us to cause source code control systems to insert/replace the text with source code known to the sccs at check-in time. Given that our current sccs checkin scripts do not reprocess a number of tag string like $Id:$ and this one, it would be my completely unofficial guess that the copyright boiler-plate for the file was copied from the corresponding x86 file, and that was left in accidently (_struct.h in x86 and ppc are new works by Ed, myself, and others as part of cleaning up namespace issues for UNIX conformance). I'd also like to point out from a signals perspective that the contents of the sigcontext and mcontext are supposed to be opaque, and other than their size, unless you are a debugger, you should not be introspecting their contents. If you are not a debugger, then you should be trying to write your code in such a way that not even the size matters outside of libc itself to let the structures change out from under you without breaking your code, if at all possible. I have tried that when I did the initial port to Mac OS X, 5 years ago or so, and failed. The situation is currently like this: 1) an fpu exception, or sigsegv, sigbus, ... occurs 2) the OS raises a mach exception, which is then converted into a unix/bsd signal 3) we catch the signal using a handler installed at startup of the app 4) we determine the nature of the signal and where it occurred 5) we change the context of the signal (here's where we need the structures) so that it will return to our own run time error handler. We also store the necessary information (exception nature, pc where it occurred, stack pointer at the exception time) in some register fields of the context struct (which are interpreted as parameters in the run time error handler) 6) we return from the signal handler 7) the kernel resumes execution in our run time error handler 8) we generate the appropriate language exception My initial version used some form of (sig)longjmp instead of steps 5 to 7 to hand over control to our run time system, but that does not work for fpu exceptions (at least not on PPC). The reason was that as long as you did not return from a signal handler, fpu exceptions remained disabled (well, you could re-enable them in the fpscr, but the kernel dropped them on floor as soon as they occurred again afterwards). I can't immediately find again where this happens in xnu, but if you are interested I could try to look it up again. Assuming the sigsetjmp happened prior to the signal handler, I would expect the mask state to be restored on siglongjmp. If it is not, I'd class that as a bug (NOTE: not a bug if you are using {set|long}jmp instead of sig{set|long}jmp). I'm not sure what alternatives I have to convert hardware/OS exceptions into language exceptions (at least not if I want to be able to provide backtraces to the consumers of those exceptions, like we do right now. You could always take and eat the Mach exception sent to your task, prior to it being converted into an AST and then into a signal. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Meaning of @OSF_COPYRIGHT@
by Jonas Maebe 22 Nov '08

22 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 22 Nov 2008, at 19:48, Terry Lambert wrote: /* * @OSF_COPYRIGHT@ */ Thanks, Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Nov 22, 2008, at 2:38 AM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: I cannot find any document anywhere explaining what this marker means. If it does mean that it is licensed like the Mach kernel sources on Sourceforge, then there is no problem for me to distribute the file (the license forbids taking away that permission, and the iPhone SDK license agreement also explicitly mentions that in those cases the NDA/no distribution/no derivative works/... requirements do not apply). There is no way you will get an official anser to a question like this on a mailing list. This is not an official support channel, even if people who happen to work at Apple sometimes hang out here and post personal opinions. For an official answer, you should contact DTS and ask. I did contact DTS with a licensing question several years ago (about permission to distribute translations of the Apple Universal Interfaces), and they redirected me to sw.license(a)apple.com. I sent an email there, and never even got an acknowledgement of my request. About a month ago, I again sent them an email asking whether or not APSL-licensed files in the iPhone SDK can be modified and redistributed under the APSL terms now that the NDA is lifted. Again, I have not heard anything back. So as far as I can tell, sw.license(a)apple.com is a black hole (except maybe if you represent a million dollar customer of Apple or so). I still have some hopes regarding my second mail because someone at Apple was going to poke them about it. Still, they obviously have other things to do than answering requests from an individual open source developer (regardless of how many commercial companies use our product). Furthermore, the @OSF_COPYRIGHT@ tag also appears in many regular Darwin files (e.g., in 517 of the xnu-1228.7.58 files). Since several people responsible for the packaging and releasing of Darwin sources are here, I hoped that they could give an indication of what it means (maybe just a reference to some licensing document somewhere on the Darwin site that Google doesn't index). In these xnu files, @OSF_COPYRIGHT@ does in fact appear to be always followed by the full OSF license in linked to in my original mail. Maybe some sort of license stripping was done for the iPhone SDK to avoid marking certain iPhone-specific files as APSL. Or conversely, maybe only the tags are present in Apple's internal sources and simply no license /insertion/ was performed based on these tags -- one more reason why I think the Darwin packagers may be able to answer my question, even if only in the sense that "based on this tag we insert this text into the sources when preparing them for distribution. The OSF license would however remain applicable in such situations (since that one is not Apple's call to remove). All that said, were I in your position, I would side-step the issue entirely by doing a machine translation at install time, which is the time-honored approach to dealing with license issues by not dealing with them. Perl, Ruby, Python, etc., all take this approach. For this particular header file (which is fortunately the only one which I need from the iPhone SDK for our base run time library), that would indeed be an option since it is so simple. General machine translation of C headers usually breaks down horribly in my experience though. But maybe gen_bridge_metadata(1) manages to work around most quirks. It would still be a pain though, since we normally distribute a compiled version of all our units (it's a Pascal compiler, producing natively compiled code). Since this header file is necessary for the system unit on which everything else depends, we'd have to distribute the sources instead, somehow find a way to get Installer.app to ask for the location of the iPhone SDK, and then translate that header and compile/install everything. That's not really user-friendly (not for us as developers, nor for our users). Not distributing anything at all (or worse, distributing a file that may make me and them liable for copyright infringement lawsuits by Apple) is obviously even less user-friendly, hence my question to see what my options are. I'd also like to point out from a signals perspective that the contents of the sigcontext and mcontext are supposed to be opaque, and other than their size, unless you are a debugger, you should not be introspecting their contents. If you are not a debugger, then you should be trying to write your code in such a way that not even the size matters outside of libc itself to let the structures change out from under you without breaking your code, if at all possible. I have tried that when I did the initial port to Mac OS X, 5 years ago or so, and failed. The situation is currently like this: 1) an fpu exception, or sigsegv, sigbus, ... occurs 2) the OS raises a mach exception, which is then converted into a unix/ bsd signal 3) we catch the signal using a handler installed at startup of the app 4) we determine the nature of the signal and where it occurred 5) we change the context of the signal (here's where we need the structures) so that it will return to our own run time error handler. We also store the necessary information (exception nature, pc where it occurred, stack pointer at the exception time) in some register fields of the context struct (which are interpreted as parameters in the run time error handler) 6) we return from the signal handler 7) the kernel resumes execution in our run time error handler 8) we generate the appropriate language exception My initial version used some form of (sig)longjmp instead of steps 5 to 7 to hand over control to our run time system, but that does not work for fpu exceptions (at least not on PPC). The reason was that as long as you did not return from a signal handler, fpu exceptions remained disabled (well, you could re-enable them in the fpscr, but the kernel dropped them on floor as soon as they occurred again afterwards). I can't immediately find again where this happens in xnu, but if you are interested I could try to look it up again. I'm not sure what alternatives I have to convert hardware/OS exceptions into language exceptions (at least not if I want to be able to provide backtraces to the consumers of those exceptions, like we do right now). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Meaning of @OSF_COPYRIGHT@
by Terry Lambert 22 Nov '08

22 Nov '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hello, The copyright notice in that file only says: /* * Copyright (c) 2004-2007 Apple Inc. All rights reserved. */ /* * @OSF_COPYRIGHT@ */ -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Nov 22, 2008, at 2:38 AM, Jonas Maebe <jonas.maebe(a)elis.ugent.be> wrote: What is the full meaning of @OSF_COPYRIGHT@ in Mach header files? Does it only mean that the file was originally written by the Open Source Foundation, or does it also automatically mean that it is licensed under the license that you can see e.g. here: http://kernelsource.svn.sourceforge.net/viewvc/kernelsource/OSF-Mach/6.1/os… ) The reason that I'm asking, is that for our compiler port for targeting the darwin/arm platform, I have to distribute a translation of Platforms/iPhoneOS.platform/Developer/SDKs/ iPhoneOS2.1.sdk/usr/include/mach/arm/_structs.h (in order to be able to properly deal with signals) I cannot find any document anywhere explaining what this marker means. If it does mean that it is licensed like the Mach kernel sources on Sourceforge, then there is no problem for me to distribute the file (the license forbids taking away that permission, and the iPhone SDK license agreement also explicitly mentions that in those cases the NDA/no distribution/no derivative works/... requirements do not apply). There is no way you will get an official anser to a question like this on a mailing list. This is not an official support channel, even if people who happen to work at Apple sometimes hang out here and post personal opinions. For an official answer, you should contact DTS and ask. All that said, were I in your position, I would side-step the issue entirely by doing a machine translation at install time, which is the time-honored approach to dealing with license issues by not dealing with them. Perl, Ruby, Python, etc., all take this approach. I'd also like to point out from a signals perspective that the contents of the sigcontext and mcontext are supposed to be opaque, and other than their size, unless you are a debugger, you should not be introspecting their contents. If you are not a debugger, then you should be trying to write your code in such a way that not even the size matters outside of libc itself to let the structures change out from under you without breaking your code, if at all possible. This email sent to site_archiver(a)lists.apple.com

1 0