Re: Unexpected non-local transfer on doing SAP to pointer coercion
Stas Boukarev <[email protected]>
| Newsgroups | gmane.lisp.steel-bank.general |
|---|---|
| Message-ID | <CAF63=13vr5iRY+HJMtPx3dNs1793gxp5yKrdgkA_x-mbMmr-sg@mail.gmail.com> |
Don't catch CONDITION, but ERROR. Or at least SERIOUS-CONDITION. On Thu, Jun 6, 2024 at 2:03 AM Michael Kappert via Sbcl-help < [email protected]> wrote: > On 05/06/2024 11.35 pm, Michał "phoe" Herda via Sbcl-help wrote: > > You can set break-on-signals to T, just mind that you'll get into a > > loop break every time a condition is signaled. Either CONTINUE your > > way out of the uninteresting conditions until you get to an > > interesting one, or try setting that value to some narrower type than > > T, for example ERROR. > > Thanks, I didn't know that. > Just to clarify, setting break-on-signals to non-nil isn't the problem. > I did that on purpose to find where the signal comes from. > > To further clarify, the problem is a condition of type > simple-compiler-note being signalled during program execution, not at > compile time, when attempting to call a foreign function defined with > CFFI:DEFCFUN. > The condition is handled in my own handler-case handling type condition, > when it's too late. > I don't see suitable continue restart. > > My apologies if after 35 years of Lisp I'm still mixing up the terminology. > Just hope someone can point me in the right direction. > > > > > _______________________________________________ > Sbcl-help mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sbcl-help > _______________________________________________ Sbcl-help mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sbcl-help