Jonas Hahnfeld schreef op vr 19-11-2021 om 14:55 [+0100]: > Am Freitag, dem 19.11.2021 um 13:48 +0000 schrieb Maxime Devos: > > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]: > > > > > - rx = scm_gc_malloc_pointerless (sizeof (regex_t), > > > > > "regex"); > > > > > + rx = scm_malloc (sizeof (regex_t)); > > > > > > > > If the regex why scm_gc_malloc_pointerless -> scm_malloc? > > > > Is rx not pointerless? > > > > > > Not sure I understand the question. We don't know what contents > > > libc > > > will write into regex_t. It could be pointers which would be bad > > > for > > > the garbage collector. > > > > OK, if that's the case, seems like a bug in the original code, not > > related to Java-style finalisation, so I would do that in a > > separate > > patch.
>From your other responses, I now know it is actually related to (non- )Java style finalisation, but my comment about ‘separate patch’ still seems to apply: > > Again, as replied in July to the same comment, it *is* a separate > patch > for exactly this reason. More concretely, it is in the same patch as that modified libguile/random.c. The patch to libguile/random.c doesn't seem to be for non-Java finalization reasons. Going by the commit message, the only possible reason I could find is: ‘There is no point in registering memory with the garbage collector if it doesn't need to do its job’ But I don't see any ‘registering memory’, only replacing scm_gc_calloc+scm_gc_free by scm_calloc+free, and without any finalisation in sight. Unless you mean with ‘registering memory’ the "random bignum chunks" argument. But that still seems unrelated to non-Java finalization. Greetings, Maxime
