Re: CVS commit: src/lib/libc/string

[David Holland <dholland-sourcechanges%netbsd.org@localhost>]

On Thu, Mar 26, 2020 at 10:54:21AM +0700, Robert Elz wrote:
 >   | I don't agree -- because applications shouldn't attempt to modify the
 >   | result, it should be const.
 > 
 > The only reason apps shouldn't modify the string is in case of
 > porting the app to an (well, some) ancient implementation.  Because
 > of the NLS requirements, the message these days (any modern
 > implementation) must be read from some external file - which means
 > the storage for it must be writable.  Nothing else (except the
 > calling thread) cares about the content of the returned message, so
 > there's no actual reason for the app to not modify it now if for
 > some wacky reason it wants to.

I fail to see any scenario in which it's legitimate for an application
to scribble in internal data belonging to libc. Why should this be
permitted?

 > The entry that was in BUGS wasn't a bug - what would be a bug would
 > be if we actually made strerror() return const char * - it wasn't
 > even a limitation (which we traditionally include in BUGS, even
 > though they're generally by design, and not accident, and not
 > really intended to be "fixed") - what it was was a rant about the
 > original design spec, and what's more, one which is no longer
 > warranted.

I don't understand. It is a bug that the library returns a writeable
pointer to data that should not be modified.

Anyway, this is moot because strerror is defined by C; but because it
*should* be const, it should be (and is) declared with __aconst in
string.h.

Please don't change that.

Also, perhaps we should swipe the text about not modifyingthe string
buffer from strsignal.3.

-- 
David A. Holland
dholland%netbsd.org@localhost