GNU bug report logs - #42296
27.0.91; Correct manual entry for 'concat' w.r.t. allocation [PATCH]

Previous Next

Package: emacs;

Reported by: Mattias Engdegård <mattiase <at> acm.org>

Date: Thu, 9 Jul 2020 15:55:01 UTC

Severity: normal

Tags: patch

Found in version 27.0.91

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log


Message #38 received at 42296 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 42296 <at> debbugs.gnu.org
Subject: Re: bug#42296: 27.0.91; Correct manual entry for 'concat' w.r.t.
 allocation [PATCH]
Date: Sat, 11 Jul 2020 14:51:06 +0200
11 juli 2020 kl. 13.52 skrev Eli Zaretskii <eliz <at> gnu.org>:

> Too definitive to my palate, sorry.

Apologies -- I do my best to read your mind.

> You may wish reading the recent long discussions of what is/should be
> and what isn't/shouldn't be immutable.

Thank you, but reading it once was quite enough.

>  Turns out some of us are very
> sensitive to "should not" being used where "we recommend you not" or
> "make sure you know what you are doing" is what actually is the truth.

Very well, here is a revised proposal:

 This function does not always allocate a new string.  Callers are
 advised not rely on the result being a new string nor on it being @code{eq}
 to an existing string.

 In particular, mutating the returned value may inadvertently change another
 string, alter a constant string in the program, or even raise an error.
 To obtain a string that can be mutated, use @code{copy-sequence} on the result.





This bug report was last modified 4 years and 312 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.