GNU bug report logs - #30675
Ask the user what to do when shr-make-table: Variable binding depth exceeds max-specpdl-size

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30675 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: bug#30675: Ask the user what to do when shr-make-table: Variable binding depth exceeds max-specpdl-size
Date: Fri, 13 Apr 2018 13:48:22 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I'd feel much better with a lower factor, e.g. some value that is just
> enough to cover this case plus some slack.  Bonus points for providing
> a defcustom with the factor, so that users could change that.

The problem is that HTML may nest arbitrarily deep, so there isn't
really any way to cover this completely.  But the larger the stack size
is, the lower the possibility for hitting the limit is.

FWIW, I haven't hit the limit in about a year, so it's rare for people
to encounter HTML that's that deeply nested.

> The idea of asking the user whether to increase by N levels sounds OK
> to me, provided that its implementation is not out-worldly hard.

I kinda feel that stack size is something that a user has little idea of
what it would mean.  Emacs: "We hit a magical limit!  Raise the limit?"
User: "Sure!"  Emacs: "Now it worked!"  I mean...  why consult the user
at all?  :-)

> Well, if I need to give my opinion on this, then blindly
> increasing the limit ten-fold is something that'd make me worry about
> a potential C stack overflow. 

Hm...  On what architectures is there a potential for a C stack
overflow?  I thought that these days, C stack overflows basically didn't
happened, and we only had the max-specpdl-size as a sanity check to
avoid deep lisp backtraces and stuff, but I may well have misunderstood
things.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.