Some uses of call/cc broken on Windows binaries
This is the root cause of the openLilyLib issues mentioned in #6361 (comment 1065230932).
oll-core/internal/iterator.scm
(https://github.com/openlilylib/oll-core/blob/master/internal/iterator.scm) does something which can be written like this:
\version "2.23.13"
#(define (list-iter lis)
(define (control-state return)
(for-each
(lambda (element)
(set! return
(call/cc
(lambda (resume-here)
(set! control-state resume-here)
(return element)))))
lis)
(return 'list-ended))
(lambda ()
(call/cc control-state)))
#(let ((iter (list-iter '(1 2 3 4))))
(ly:message "~s" (iter))
(ly:message "~s" (iter))
(ly:message "~s" (iter))
(ly:message "~s" (iter))
(ly:message "~a" (iter))
(ly:message "~a" (iter)))
This is essentially a (somewhat contorted IMHO) way of saying
#(use-modules (ice-9 match))
#(define (list-iter lis)
(let ((state lis))
(lambda ()
(match state
((a . b)
(set! state b)
a)
(()
'list-ended)))))
The result of the version with call/cc
on Linux is this, as expected:
1
2
3
4
list-ended
list-ended
The result on Windows is:
1
then after a few seconds, a crash with return code -1073741784.
Because Guile interacts with C code, it implements call/cc
in the only possible way that works with C code: capture the whole call stack (!) and state of registers. Reinstating the continuation copies back the stack from the continuation object. Obviously, the sanity of this logic is very platform-dependent. Apparently, something is broken in Guile 2 on our MinGW cross-compiles.