> Date: Fri, 29 May 2020 15:48:41 +0200 > From: Ingo Schwarze <[email protected]>
Hi Ingo, > Hi Marc, I'm not Marc, but close enough ;). > do i understand correctly that you intend to say: there are > legitimate reasons to use these xlocale.h functions in portable > software, in particular in portable libraries, so we should probably > have them all, or at least most of them? Yes. And we probably need most of them since if you implement some, code is going to assume the others are there as well. > I see your point that using functions like isdigit(3) can (at least > in theory) be dangerous when running on systems that support > exceedingly weird single-byte 8-bit locales. (As opposed to only > supporting one single single-byte locale, which is 7-bit, like we do.) > > I'm not even sure the question matters whether xlocale.h is the best > possible way to avoid such issues. To make support desirable, it > might be sufficient that xlocale.h is one reasonable way and that > some amounts of useful software actually use it. For example the libc++ that we have in base uses it. There is a stub implementation but it has given us quite a bit of grief. > Marc Espie wrote on Thu, May 28, 2020 at 05:52:12PM +0200: > > On Tue, May 26, 2020 at 12:13:02AM +0200, Ingo Schwarze wrote: > > > > my impression is there are two totally independent topics in this > > > thread. > > > > > > 1. Whether and how to make things safer, ideally terminating the > > > program in a controlled manner, if it uses functions that are > > > not thread-safe in an invalid manner. I'm not addressing that > > > topic in this mail. > > > > > > 2. Whether we want additional non-standard xlocale.h functions > > > in our libc. > > > > > > Regarding topic 2, let me say up front that i do not feel strongly > > > either way. It seems to me this is mostly a question for porters. > > > If some functions are widely used - even if non-standard - and help > > > avoid porting hassle, then sure, let's have them unless they cause > > > excessive fuss. But the latter does not seem likely here. > > > > > > There are a number of functions that seem likely useful to me off > > > the top of my head, for example: querylocale, nl_langinfo_l, > > > MB_CUR_MAX_L, wcwidth_l > > > > > > In general, i must say i like the whole xlocale.h business not all > > > that much: in a nutshell, it is doubling the number of half the > > > functions under the sun, which usually indicates poor design in the > > > first place, and then the vast majority of these additional functions > > > are almost useless on any operating system and totally useless on > > > OpenBSD. Like, i mean, btowc_l(3)? Or even the isdigit_l(3) which > > > we already have? You must be choking, Mr. Chisnall! I don't think > > > stuff should be added because it is out there, but only if there is > > > at least some porting benefit. > > > > > > Regarding the FreeBSD headers, i like them even less. There are both > > > terrible design choices and terrible implementation choices. Regarding > > > design, it appears that you *must* #include <xlocale.h> after other > > > headers - if you include it before, it won't work. Regarding > > > implementation, there is quite repulsive macro abuse in xlocale/_ctype.h; > > > but probably that can be unrolled in LibreSSL style. Either way, none > > > of that hinders providing them if doing so yields benefit. > > > > > > See below for a list of functions that i drafted extremely quickly, > > > so beware of errors and omissions. The point isn't to present a > > > definite plan. The point is merely to demonstrate the sheer fatness > > > of the animal and to give a first impression of the degree to which > > > it stinks and grunts from most of its ends. > > > > > > If any of this is needed, do porters already know which functions > > > are in particularly high demand? Do you have any idea how to find > > > out which ones are actually useful for porting purposes? > > > > Serendipity > > > > Today, I looked at an older library for audit purposes. > > > > Library is called udns. > > > > If you look at the code, there's a lot of apparently useless reinvention, > > like the code explicitly checks for digits using c >= '0' && c <= '9' > > patterns > > (or isprint for that matter). > > > > Thinking some more, I realized why: this is library code, so it can't assume > > it's running under any kind of sensible locale unless it has asserted it > > itself. > > > > In that specific context, isdigit_l and friends make a lot of sense. > > Either that, or systematic uselocale wrappers for any function that can be > > called from outside. > > > > (yes, I now that isdigit/isspace are not a problem on OpenBSD, but they can > > be elsewhere!) >
