I reported a couple of bugs related to pure space.  One was a duplicate that had been closed as "won't fix".  The other hasn't gotten any response, though that could be due to the lack of details.

The one closed as "won't fix" (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46916) should really be fixed, even if not by the originally submitted patch.  The response from Eli that prompted that status was along the lines of "why not just increase the pure space"?  The answer is: I didn't see any warnings about pure space being exhausted, even though it turned out I was at least 12MB short.  

The fix should just do away with the "small size" increment and allocate whatever is needed, under the assumption that the user will have to increase pure space and recompile regardless.  There are too many assumptions in the code that test purity by distance from the base pure address to rely on a dump where pure space is exhausted.

The other issue arose from record created by eieio that pun the type of a class descriptor class to itself.   purecopy does not track cyclic structures, so diverges and causes a segmentation fault.  I put in a special case check that prevents the immediate problem, but a real solution would have to memoize the input structure if the intent of hash consing is to create singletons and not just read-only constants.  The singleton property is what seems to be of interest for eieio class descriptor records.

Generally, are fixes to pure space worth submitting, given the plan to decommission it, or will they just be ignored?  I'm still waiting on clearance from my employer to submit patches, unfortunately.  

Lynn