Jean Abou Samra <[email protected]> writes: > Re call/cc: I would actually like to use > static_cast<scm_t_dynwind_flags> (0) > and not SCM_F_WIND_EXPLICITLY. I have no idea whether the stuff I write > is going to interact gracefully with rewinding the stack via continuations, > and I honestly don't want to wonder.We're using C++ (on contrary to Guile, > which is primarily tailored for C), so most allocations (e.g., vectors) are > managed via C++ RAII. This means that C++'s stack unwinding and > Guile's don't > interact, so you can easily crash LilyPond with continuations and > such, by making > some expression return twice and arranging for it to cause double free. This > is the first example that came to my mind: > > \version "2.23.7" > > { > \override NoteHead.X-extent = > #(let ((cont #f)) > (lambda (grob) > (if cont > (cont '(0 . 0)) > (call/cc > (lambda (c) > (set! cont c) > '(0 . 0)))))) > c d > } > > > > Frankly, I don't think we need to bother at all about such stuff. If > the user is willing this hard to shoot themselves in the foot, we > can't prevent them.
It's worth keeping in mind that dynamic programming (like trying to figure out the best breakpoint sequence) naturally lends itself to juggling a set of best continuations so far (a continuation is more versatile to build upon than a static description of a partial solution). But the main control flow strategies are certainly maintained by LilyPond itself, so we are mainly shooting ourselves in the foot by blocking certain programming practices that make your head ache but may actually be a good fit for "under the hood". So it's stuff that there is no point in bending over backwards to get right, but if we see a reasonably easy and affordable way to do it "continuation-safe", it's probably worth doing it and thus keeping more options easily accessible for the future. One example of "weird control flow" I had to revert to is map-markup-commands even if it does not go to the depths of restarting continuations but "only" throws parts of a solution. -- David Kastrup
