On Sun, Nov 01, 2015 at 01:36:53AM +0100, felix.winkelm...@bevuta.com wrote: > Is this really necessary? I think runtime.c is already complicated enough as > it > is. I understand your intent, but I'm always wary of "arbitrary fixes to > reasonable > limitations, just because they are limitations". I think an arg-limit makes > sense, > there are certain constructs that don't scale. If I have to pass 10 million > arguments > to a procedure, I'm probably doing something wrong.
At the moment the limit isn't 10 million but more like 4096 :) I know what you mean, but we've seen that in practice there are some libraries that heavily rely on apply, most notably SSAX's sxml transformations. And an XML element with 4096 child nodes isn't especially huge. One of the tricky parts about the temporary stack size is that it limits the parameter count, but *only* when the affected procedure is invoked precisely when the stack is full. This could result in extremely tricky debug situations where a procedure works fine by itself, but in a program under *certain conditions* it would fail with an assertion error. That's what happens now if you exceed the parameter limit in a direct invocation. Of course this is even rarer than manyarg apply, but it could happen due to macro expansion. I don't think the change is that invasive; it only really affects one C function, and I've cleaned up some cruft that's no longer needed and simplified a test. Alternatively, we could just raise the limit of 4096 to something higher (what's an acceptable limit?), but that means pre-allocating more memory that's rarely actually used. I think the less effectively "useless" memory we pre-allocate, the better. Cheers, Peter
signature.asc
Description: Digital signature
_______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
