> > > Obviously, our locale support still sucks, this patch is mostly > > > providing the API for filling the blanks later. > > Which blanks exactly? Locale features we don't have, such as collation?
Yes. The features why for example PostgreSQL won't sort tables correctly, which if you live in a country with weird characters in their language is... quite unfortunate. I was planning on bringing specifically LC_COLLATE support for a long time, but it's quite a lot of work. (and testing, and bugfixing with languages I don't even know existed) > > How much did the ramdisks grow by when you built release with this? > > Having just freed up a bunch of space on the ramdisks, I'll be pissed if > > we squander it all immediately. No objections against #ifndef SMALL_KERNEL-ing the big bits. > I'm not very excited about xlocale. If the only goal here is an API > shim to compile a C++ library, can't we put the shim somewhere else > than libc? Like the misc/libutf8 port we used to have? Thought about it too, but since apps expect to find this stuff in libc, I went for a libc diff hoping that porters will have their lives easier. The functions I ported were the ones ld-2.17 complained about. I have no idea whether that port is complete and I don't claim the diff to be ready. It gets the job done at the cost of being huge and probably wrong in places, and is open for discussion. I don't care about xlocale either. What'd I like is to have C++11 working out of the box for the next release (Is that real?) and hopefully collation support some time in the future. Later in the process I noticed there is an even smaller shim intended for Solaris as a part of libcxx, but my thoughts were: - Locale has always been a pain in the ass, but something users demand. (or is it just me with postgresql?) - Sharing this stuff with FreeBSD will make our lives easier should anything go wrong with it. Less work for us + satisfied customers. - We don't have to be complete, or even advertise it very much. But stuff that is increasingly popular (like C++11) will work out of the box. The ability to use modern toolchains for ports should make the latency-savvy desktop users happier. - Since a lot of operating systems have now adopted solutions (being it xlocale or others), I suspect libcxx maintainers won't be very happy about #ifdef __OpenBSD__ <remove half of the functionality> Please correct me if the philosophy is wrong. Or better, suggest other ways forward :-) -- Martin Pelikan
