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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 25 Mar 2020 20:51:25 +0000
    From:        David Holland <dholland-sourcechanges%netbsd.org@localhost>
    Message-ID:  <20200325205125.GA11098%netbsd.org@localhost>

  | 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.