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

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Mattias Engdegård <mattiase <at> acm.org>
Cc: 42296 <at> debbugs.gnu.org
Subject: bug#42296: 27.0.91; Correct manual entry for 'concat' w.r.t. allocation [PATCH]
Date: Sat, 11 Jul 2020 09:17:30 -0700 (PDT)

> >  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.
> 
> Fine with me, with one correction: last sentence will sound better if
> reworded like this:
> 
>   To obtain a string that you can safely mutate, use
>   @code{copy-sequence} on the result.

FTR, I think that the doc of `concat' should really
make clear that it (now, and apparently for a while
now) has this odd (yes) behavior of not guaranteeing
a new string.  Not sure why we made this change, but
I imagine it was in a zeal to optimize.

At a minimum, please make this very clear, and say
explicitly that to ensure that you get a new string
you can use `copy-sequence' (as you've mentioned),
and that you can alternatively use `seq-concatenate':

 (seq-concatenate 'string &rest SEQUENCES)

Previous Next

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