bug#23912: 25.0.95; Abort in gc when working with streams

[Michael Heerdegen <michael_heerdegen@web.de>]

Hello Richard,

> I pinged RMS.  It's important for me to hear his opinion on this.

Can you please tell us if we should wait for your answer, or if you
just don't remember?  No need to read the complete thread; this was our
question:

  Richard, do you perhaps remember, or can try to second-guess, why do
  we set the abort_on_gc flag inside prin1-to-string?  I mean this
  fragment of print.c:
  
    /* Save and restore this: we are altering a buffer
       but we don't want to deactivate the mark just for that.
       No need for specbind, since errors deactivate the mark.  */
    Lisp_Object save_deactivate_mark = Vdeactivate_mark;
    bool prev_abort_on_gc = abort_on_gc;
    abort_on_gc = true;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  
    Lisp_Object printcharfun = Vprin1_to_string_buffer;
    PRINTPREPARE;
    print (object, printcharfun, NILP (noescape));
    /* Make Vprin1_to_string_buffer be the default buffer after PRINTFINISH */
    PRINTFINISH;
  
    struct buffer *previous = current_buffer;
    set_buffer_internal (XBUFFER (Vprin1_to_string_buffer));
    object = Fbuffer_string ();
    if (SBYTES (object) == SCHARS (object))
      STRING_SET_UNIBYTE (object);
  
    /* Note that this won't make prepare_to_modify_buffer call
       ask-user-about-supersession-threat because this buffer
       does not visit a file.  */
    Ferase_buffer ();
    set_buffer_internal (previous);
  
    Vdeactivate_mark = save_deactivate_mark;
  
    abort_on_gc = prev_abort_on_gc;
  
  Why do we want to prevent GC while working on Vprin1_to_string_buffer?
  It's just a buffer, and AFAICT we just collect the printed stuff
  there.  And yet this code that tries to avoid GC was there since long
  ago, first as GCPRO, and now as this flag.  What bad things could
  happen if we just remove it?

FWIW, I didn't notice bad things after I removed it locally (several
weeks ago).


Many thanks!

Michael.