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 <jo...@bec.de> > Message-ID: <20200324131330.ga60...@bec.de> > > | 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