Re: Issue 8 POSIX changes coming

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

    Date:        Tue, 24 Mar 2020 15:48:07 +0100
    From:        Joerg Sonnenberger <joerg%bec.de@localhost>
    Message-ID:  <20200324144807.GA63045%bec.de@localhost>

  | strerror is already thread-safe.

Ours is, I know, but assuming that isn't portable, it isn't promised,
and some implementations are not.   (My man page changes say all of
that already).

  | There is the question on whether we should avoid copying internally
  | for the common case, but that's a minor optimisation at best.

Not a current concern anyway - how the functions are implemented is
a whole different issue.

But in that area, I am not much enamoured with the way that strerror(-1)
currently returns (POSIX locale) "Unknown error: 4294967295" all in the
name of "cute" coding, and I might fix that sometime.

  | I am aware of that. But it is rare enough that it doesn't seem to
  | justify having a second interface.

And having _l variants for *all* functions which use the global locale
isn't either?

  | It also seems to be a micro-optimisation at best.

More like it provides consistency.

But for now, I think I'll (mostly) just comment out the strerror_lr()
parts I added to the man page, leave it there for possible future use,
and (perhaps tomorrow, no, that's actually later today, here) commit
the rest of what I have.

  | On the const front: I've mostly given up on const correctness of return
  | values in C...

There are times it matters (it really did once for our strerror()) but
for this one now, it seems unnecessarily pedantic, given that the
standard defined interface doesn't include it.

So I think I'll just delete that paragraph as well, in a separate commit,
so it is easy to revert if desired later.

kre