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 [email protected]
