Re: Issue 8 POSIX changes coming

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

    Date:        Tue, 24 Mar 2020 14:13:30 +0100
    From:        Joerg Sonnenberger <joerg%bec.de@localhost>
    Message-ID:  <20200324131330.GA60335%bec.de@localhost>

  | Yes, so far it has been intended only for internal use as strerror_l has
  | been in discussion as recommented public interface for a long time. So
  | strerror_l really is the locale-specific variant of strerror_r.

It is really the locale-specific, and thread safe, version of strerror().

That some people believe the only use for strerror_r() is as a thread safe
variant of strerror() is unfortunate, but it also allows multiple error
numbers to be translated at once, in code something like

	if ((fd = open(path, whatever)) < 0) {
		err1 = errno;
		if (fd = open(path, O_CREAT|whatever)) < 0)) {
			err2 = errno;
			strerror_r(err1, ebuf1, sizeof ebuf1);
			strerror_r(err2, ebuf2, sizeof ebuf2);
			fprintf(stderr, "%s: open failed: %s,\n"
					"%.*s  create also failed: %s\n",
				path, ebuf1, ebuf2, stelen(path), "");
			return -1;
		}
	}

which strerror_l() can only handle by doing a strcpy() of its result
into a local buffer, which is annoying (putting a wrapper around strerror_r
to have it return the buffer would allow the whole thing to be made args
to fprintf, which would make it even simpler to use - more akin to
strerror() or strerror_l() from that perspective - but that's trivial for
any app that needs it to do for itself).

Are there any objections to making strerror_lr() user visible?

For those occasions when strerror_r() is useful (glibc brokenness of
that function ignored here) but the locale parameter is also needed,
having strerror_lr() available seems like it would be a win.

  | > Also, can someone explain strerror_ss() and strerror_r_ss()
  |
  | They are for internal use only. [...]

OK, that's about what I assumed - those can simply be ignored.


One more thing related to this - when I was doing the man page update (which
I have done, but not committed, since it is done assuming that strerror_lr()
will need documenting as well - changing that will just mean deleting stuff
if we decide not to do it) I came across this (ancient) issue in the bugs:

     The return type for strerror() is missing a type-qualifier; it should
     actually be const char *.

which would apply to strerror_l() as well, when it is added.   Except, this
is no longer really true is it?   Currently I have left that there (with
strerror_l() added) but preceded it with a big comment...

.\" Is this following para really true any more?   All the strerror()
.\" family of functions return the result in a malloc'd array (or if
.\" ! __REENTRANT a static buffer in the function) or in a buffer
.\" provided by the caller - nothing actually returns a pointer into
.\" sys_errlist[] any more (strerror_ss() excepted, but we ignore that).
.\" The POSIX (and historic) functions had no "const" qualifier.
.\" POSIX does say that callers must not (attempt to) modify the result,
.\" but for our implementation I see no defect that can cause.

The "following para" is the one quoted in this e-mail earlier.

I think that paragraph (those 2 lines) can simply be deleted now,
if desired, words admonishing against modifying the result returned by
strerror() or strerror_l() can be added earlier.

kre