Hello, "Neil Jerram" <neiljer...@googlemail.com> writes:
> That's good, but I think I didn't explain the possible problem fully, > i.e. that the substitute won't work. Because of how Guile saves and > restores continuations (by copying the stack), and how it uses alloca > to create space for debug information on the stack, we must have an > alloca() that really does use the stack, and not one that uses the > heap. And when I last checked, the common substitute definition of > alloca() uses the heap. Aaah, you're right. Then we should use the `alloca-opt' module instead, which does what we want AFAIU. (Note that systems without `alloca ()', are probably very rare.) > master has a line "serial 9", branch_release-1-8 doesn't. I believe > it's a standard of some kind to have a "serial" line, so we added it > in master, but preferred to avoid perturbing 1.8.x. Right, it's "good practice" (info "(automake) Serials"). >>> eval.c/eval.i.c >>> - still need to compare old eval.c against new eval.i.c >>> - why does eval.i.c contain code that is common to both modes and that >>> is not compiled twice? >> >> Like what? The top of the file is in `#ifdef DEVAL'. > > I would have thought that the point of eval.i.c is to hold the code > that gets compiled twice (debug and non-debug). If there is #ifdef > DEVAL code in eval.i.c, it seems to be better to move it back to > eval.c. Agreed. >>> SCM_INTERNAL (grep diffs for SCM_INTERNAL to get list of affected functions) >> >> Speaking of which, some functions were left external (e.g., >> `scm_i_string_chars ()') under the assumption that if we changed that in >> 1.8 (which was my plan back then) it would break apps. We may need to >> revise that. > > I can't immediately remember what the latest consensus on that was... IIRC, nobody cares. :-) Thanks, Ludo'.
