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
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 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 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
Homework ?
I think it would also be better to only walk/match the
Header.data and header_keys only once (using the generated switch
statement that Vladimir suggested). So your Headers struct should
have a parse() function, which will match all of the headers to
the keys and store them
On Tuesday, 20 February 2018 at 03:59:06 UTC, psychoticRabbit
wrote:
On Monday, 19 February 2018 at 12:01:31 UTC, Jonathan M Davis
wrote:
ok... so I decided to dig into it a little further.
seems the problem relates to a single line, in dget.d
pragma(lib, "curl");
I just commented out
