bug#27571: C stack overflow from `prin1' on deeply nested lisp object.

[Keith David Bershatsky]

From a layman's perspective, it appears to me that Emacs disregards `ulimit -S 
-s unlimited` on OSX 10.6.8 when typed into the terminal before launching 
Emacs.  To the extent that Emacs can be persuaded to obey the "unlimited" case 
explicitly, that sounds like a viable solution.  I must admit, however, that I 
am unfamiliar with how this all works.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [01-09-2018 04:58:34] <09 Jan 2018 07:58:34 -0500>
FROM:  Noam Postavsky <npostavs@users.sourceforge.net>
> 
> Keith David Bershatsky <esq@lawlist.com> writes:
> 
> > I have determined that bug #27571 was introduced on November 19, 2016
> > with commit c61ee94959ba96b2a327df0684593f7e569e30be.  The following
> > patch to the Emacs 26 branch as of today (01/08/2018) reverses the
> > commit and enables the test below to be completed successfully.
> >
> > [FYI: I am on OSX 10.6.8 and am manually increasing the stack limit
> > with `ulimit -S -s unlimited` so that I can have rather large custom
> > undo-tree histories.]
> 
> By "broken" you mean that it prevents the `ulimit -S -s unlimited` trick
> from working?  Perhaps it's just a matter of detecting this "unlimited"
> case explicitly.