On Mon, Dec 7, 2015 at 10:02 AM, Jens Alfke <j...@mooseyard.com> wrote:
>
> On Dec 7, 2015, at 9:40 AM, Dmitri Gribenko <griboz...@gmail.com> wrote:
>
> There are
> just two processes -- one is performing a trap, and another one is the
> test harness that verifies that the other process terminated.
>
>
> Ah — I thought it was some type of in-process exception/signal handler.
Well, if we used that, then we wouldn't be testing in the same
environment as production code would run in.
Even more, when a compiler sees that the process is going to trap
anyway, it can omit some cleanups, like ARC releases, which will lead
to memory leaks and other surprising behavior.
While it is technically possible to intercept the control flow after a
Swift trap, I would not recommend doing that even for test purposes,
and even less for production code, for the reasons I described.
> What would you like to know?
>
>
> Given the above, not much :) I suppose an assertion failure just raises a
> SIGABORT or something similar?
It performs a UD2 instruction on x86, or equivalent on other
platforms. stdlib/public/core/AssertCommon.swift if you are
interested.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <griboz...@gmail.com>*/
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
