Hmm... I took a second look at the problem report and I don't think it should have been closed -- even with overflow checking turned on, we return a different answer than CPython does.
It's useful when filing a report like this to include the output from both CPython and IronPython. I've reopened the bug and added this information. On Thu, Aug 28, 2008 at 9:39 PM, Curt Hagenlocher <[EMAIL PROTECTED]>wrote: > For both IronPython 1 and 2, we don't enable stack overflow checking by > default because it can cause noticeable perf hits under some circumstances. > You can enable it from the command-line or by executing > sys.setrecursionlimit(n) for some more finite value of n. This will only > affect code generated after the command is executed, so it should be run > fairly early in the process' lifespan. > > > On Thu, Aug 28, 2008 at 9:28 PM, Jeff Hardy <[EMAIL PROTECTED]> wrote: > >> Hi, >> Issue #17810 ( >> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17810) >> is marked 'Closed', with a rather cryptic comment. I'm curious as to >> whether the infinite recursion was fixed, or whther -X:MaxRecursion is >> supposed to be some sort of workaround. >> >> Thanks, >> Jeff >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > >
_______________________________________________ Users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
