Date: Wed, 25 Mar 2020 20:51:25 +0000 From: David Holland <dholland-sourcechan...@netbsd.org> Message-ID: <20200325205125.ga11...@netbsd.org>
| 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. Note that when strerror_l() was created, the opportunity to make that return const char * existed - const existed in C by then, which it didn't when strerror() was invented - but wasn't taken, as it was clear by its very design that strerror_l had to return a pointer to writable memory, so it was made char * and not const char *. | What it points to internally doesn't matter... True, if the interface had been to return const char *. 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. kre ps: I've never seen, and cannot really imagine, an app that would ever want to modify the result from strerror(), so none of this really matters anyway.