Re: Issue 8 POSIX changes coming

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Tue, Mar 24, 2020 at 09:27:54PM +0700, Robert Elz wrote:
>     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().

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

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

I am aware of that. But it is rare enough that it doesn't seem to
justify having a second interface. It also seems to be a
micro-optimisation at best.

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

Joerg