Policy on pure space-related fixes

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

Hi,
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

[-- Attachment #2: Type: text/html, Size: 1996 bytes --]