On Fri, May 29, 2020 at 03:48:41PM +0200, Ingo Schwarze wrote: > Hi Marc, > > 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? > > 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. > > Yours, > Ingo
I'm starting to believe that a xlocale-like model makes more sense than the current model in a lot of cases. Think about it: a lot of locale goo deals with text processing. NOT input/output, but data processing. It seems obvious to me that at least SOME locale information has to be attached to the data, and so each time you have to process the data, you have to choose the right locale. setlocale() is out in modern multi-threaded programs. both uselocale() and xlocale.h functions are NOT portable to everything. xlocale.h allows you to attach the locale to the data uselocale() requires you to do a back&forth each time you want to process data if you don't want to disturb other things. It's hidden globals all over again. It's no accident that libc++ will use xlocale.h functions if they're around. As every other modern library should.
