On Wednesday, 22 May 2019 at 16:37:36 UTC, Lobachevsky wrote:
I have been experimenting with setjmp / longjmp under Windows
as a way to break out of an endless loop. With my experiments,
longjmp appears to silently exit the process, no stack trace,
nothing. Black emptiness.
I don't think
I have been experimenting with setjmp / longjmp under Windows as
a way to break out of an endless loop. With my experiments,
longjmp appears to silently exit the process, no stack trace,
nothing. Black emptiness.
I stared with the C program described in
On Thursday, 20 September 2018 at 12:11:55 UTC, SrMordred wrote:
Ok, after a better look at the sources I finally got it:
setjmp is a macro.
the true function signature is "int _setjmp(jmp_buf, void*)"
the void* is the current function address which in mingw
sources are capture by
Ok, after a better look at the sources I finally got it:
setjmp is a macro.
the true function signature is "int _setjmp(jmp_buf, void*)"
the void* is the current function address which in mingw sources
are capture by "__builtin_frame_address(0)".
And I did´t look yet to see if Dlang have an
On Wednesday, 19 September 2018 at 11:12:41 UTC, Diederik de
Groot wrote:
On Wednesday, 19 September 2018 at 11:06:23 UTC, Diederik de
Groot wrote:
On Tuesday, 18 September 2018 at 19:45:18 UTC, SrMordred wrote:
Only the exact size of the jmp_buf is important (not the
details about the
On Wednesday, 19 September 2018 at 11:06:23 UTC, Diederik de
Groot wrote:
On Tuesday, 18 September 2018 at 19:45:18 UTC, SrMordred wrote:
Only the exact size of the jmp_buf is important (not the
details about the content). We only call a function with it, we
never look inside.
I don't own
On Tuesday, 18 September 2018 at 19:45:18 UTC, SrMordred wrote:
On Tuesday, 18 September 2018 at 03:09:18 UTC, Mike Parker
wrote:
On Tuesday, 18 September 2018 at 00:24:23 UTC, SrMordred wrote:
Yes, i'm using signal(SIGSEGV, sigfn_t func), it catches
correctly, but end the execution after.
On Tuesday, 18 September 2018 at 20:01:48 UTC, SrMordred wrote:
longjmp is crashing so may be related to the struct declaration.
Well just found a thread of the same problem, just that in my
case with 64x crashes too.
https://forum.dlang.org/post/mmxwhdypncaeikknl...@forum.dlang.org
longjmp is crashing so may be related to the struct declaration.
On Tuesday, 18 September 2018 at 03:09:18 UTC, Mike Parker wrote:
On Tuesday, 18 September 2018 at 00:24:23 UTC, SrMordred wrote:
Yes, i'm using signal(SIGSEGV, sigfn_t func), it catches
correctly, but end the execution after.
I find the alternatives of setjmp/longjmp and sigaction, but
On Tuesday, 18 September 2018 at 00:24:23 UTC, SrMordred wrote:
Yes, i'm using signal(SIGSEGV, sigfn_t func), it catches
correctly, but end the execution after.
I find the alternatives of setjmp/longjmp and sigaction, but
none are avaliable on windows afaik.
setjmp/longjmp are available on
On Tuesday, 18 September 2018 at 00:24:23 UTC, SrMordred wrote:
On Tuesday, 18 September 2018 at 00:12:35 UTC, Diederik de
Groot wrote:
On Monday, 17 September 2018 at 23:44:41 UTC, SrMordred wrote:
[...]
You can use core.stdc.signal
nothrow @nogc @system sigfn_t signal(SIGSEGV, sigfn_t
On Tuesday, 18 September 2018 at 00:12:35 UTC, Diederik de Groot
wrote:
On Monday, 17 September 2018 at 23:44:41 UTC, SrMordred wrote:
[...]
You can use core.stdc.signal
nothrow @nogc @system sigfn_t signal(SIGSEGV, sigfn_t func)
To catch the signal
With a handler signature of:
enum void
On Monday, 17 September 2018 at 23:44:41 UTC, SrMordred wrote:
Its possible to use setjmp/longjmp on windows?
Or, to be straight to my problem: its possible to continue
execution after a SIGSEGV(or any other failure/signal) with
betterC and windows?
You can use core.stdc.signal
nothrow @nogc
Its possible to use setjmp/longjmp on windows?
Or, to be straight to my problem: its possible to continue
execution after a SIGSEGV(or any other failure/signal) with
betterC and windows?
15 matches
Mail list logo
