Re: partial xlocale(3) port from FreeBSD
Commenting differences I find between your patch and the one I sent
On Tue, Oct 15, 2013 at 03:32:29PM +0200, Martin Pelikan wrote:
Index: Makefile
+CFLAGS+=-D__NO_TLS
I had removed parts that used TLS, but this is better.
Index: arch/amd64/gdtoa/strtold.c
I didn't have this (neither for other architectures, however I
concentrate in amd64).
Index: citrus/citrus_none.c
...
+int
+_none_init(struct xlocale_ctype *l, _RuneLocale *rl)
+{
+ l-__mbrtowc = _citrus_none_ctype_mbrtowc;
+ l-__mbsinit = _citrus_none_ctype_mbsinit;
+ l-__mbsnrtowcs = _citrus_none_ctype_mbsnrtowcs;
+ l-__wcrtomb = _citrus_none_ctype_wcrtomb;
+ l-__wcsnrtombs = _citrus_none_ctype_wcsnrtombs;
+ l-runes = rl;
+ l-__mb_cur_max = 1;
+ l-__mb_sb_limit = 256;
+ return (0);
+}
...
+struct xlocale_ctype __xlocale_global_ctype = {
...
+struct xlocale_ctype __xlocale_C_ctype = {
I put that in locale/none.c
+struct xlocale_collate {
I put in collate.h
+struct xlocale_collate __xlocale_global_collate = {
+ {{0}, C}, 1, 0
+};
+struct xlocale_collate __xlocale_C_collate = {
+ {{0}, C}, 1, 0
+};
In collate.c (I had forgotten {{0}, C}, thanks, fixed!)
Index: gdtoa/gdtoaimp.h
+typedef struct _xlocale *locale_t;
Wouldn't be better #include xlocale.h ?
Index: gdtoa/strtod.c
Index: gdtoa/strtodg.c
Index: gdtoa/strtof.c
Index: gdtoa/strtorQ.c
Index: gdtoa/strtord.c
Index: gdtoa/strtorx.c
I didn't have these
Index: locale/Makefile.inc
- _wctrans.c wcsxfrm.c
+ _wctrans.c wcsxfrm.c xlocale.c ctype.c runetype.c tolower.c toupper.c
I added
collate.c nextwctype.c none.c xlocale.c
MLINKS+=setlocale.3 localeconv.3 \
iswalnum.3 iswalpha.3 \
iswalnum.3 iswblank.3 \
Here I added:
iswalnum.3 iswalpha.3 \
mblen.3 mblen_l.3\
mbrtowc.3 mbrtowc_l.3\
mbsinit.3 mbsinit_l.3\
mbstowcs.3 mbstowcs_l.3\
mbtowc.3 mbtowc_l.3\
setlocale.3 localeconv.3 \
towlower.3 towlower_l.3 \
towlower.3 towupper_l.3
wcstombs.3 wcstombs_l.3 \
wctob.3 wctob_l.3 \
wctomb.3 wctomb_l.3 \
mbsrtowcs.3 mbsnrtowcs_l.3 \
mbsrtowcs.3 mbsrtowcs_l.3 \
wcsrtombs.3 wcsnrtombs.3 \
wcsrtombs.3 wcsrtombs_l.3 \
wcsrtombs.3 wcsnrtombs_l.3
Index: locale/__mb_cur_max.c
#include sys/types.h
#include limits.h
+#include wchar.h
+#include mblocal.h
Not needed
Index: locale/btowc.c
...
wint_t
-btowc(int c)
+btowc_l(int c, locale_t l)
{
- mbstate_t mbs;
+ static const mbstate_t initial;
+ mbstate_t mbs = initial;
char cc;
wchar_t wc;
+ FIX_LOCALE(l);
if (c == EOF)
return (WEOF);
@@ -44,9 +51,13 @@ btowc(int c)
* which detects error return values as well as impossible byte
* counts.
*/
- memset(mbs, 0, sizeof(mbs));
cc = (char)c;
- if (mbrtowc(wc, cc, 1, mbs) 1)
+ if (XLOCALE_CTYPE(l)-__mbrtowc(wc, cc, 1, mbs) 1)
return (WEOF);
return (wc);
+}
I'm using
wint_t
btowc_l(int c, locale_t loc)
{
mbstate_t mbs;
char cc;
wchar_t wc;
if (c == EOF)
return (WEOF);
/*
* We expect mbrtowc() to return 0 or 1, hence the check for n 1
* which detects error return values as well as impossible byte
* counts.
*/
memset(mbs, 0, sizeof(mbs));
cc = (char)c;
if (mbrtowc_l(wc, cc, 1, mbs, loc) 1)
return (WEOF);
return (wc);
}
Other functions like mbrlen_l, mbtowc_l I implemented in similar way.
Index: locale/localeconv.c
I didn't have this
Index: locale/mblocal.h
...
+#include runetype.h
Here (an wherever runetype.h is included) I have
#include runetype.h
Index: locale/multibyte_citrus.c
size_t
-mbrtowc(wchar_t *pwc, const char *s, size_t n, mbstate_t *ps)
+mbrtowc_l(wchar_t *pwc, const char *s, size_t n,
+mbstate_t *ps, locale_t locale)
{
static mbstate_t mbs;
struct _citrus_ctype_rec *cc;
+ /* XXX xlocale not yet implemented */
+ (void) locale;
if (ps == NULL)
ps = mbs;
cc = _CurrentRuneLocale-rl_citrus_ctype;
return (*cc-cc_ops-co_mbrtowc)(pwc, s, n, _ps_to_private(ps));
}
This one I implemented:
size_t
mbrtowc_l(wchar_t *pwc, const char *s, size_t n, mbstate_t *ps, locale_t l)
{
static mbstate_t mbs;
struct _citrus_ctype_rec *cc;
if (ps == NULL)
ps = mbs;
FIX_LOCALE(l);
_RuneLocale *rl = XLOCALE_CTYPE(l)-runes;
cc = rl-rl_citrus_ctype;
return (*cc-cc_ops-co_mbrtowc)(pwc, s, n, _ps_to_private(ps));
}
size_t
-mbsrtowcs(wchar_t *dst, const char **src, size_t len, mbstate_t *ps)
+mbsrtowcs_l(wchar_t *dst, const char **src, size_t len,
+mbstate_t *ps, locale_t locale)
{
static mbstate_t mbs;
+ /* XXX xlocale not yet implemented */
+ (void) locale;
if (ps == NULL)
ps = mbs;
return (mbsnrtowcs(dst, src, SIZE_MAX, len, ps));
}
This
Re: partial xlocale(3) port from FreeBSD
On Mon, Oct 21, 2013 at 12:45:58AM +0200, Martin Pelikan wrote: 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) Indeed, doing collation properly (i.e. with Unicode, not just 8 bit characters like FreeBSD does) really is a non-trivial effort. It requires some expertise in linguistics and a solid understanding of the unicode standard. You'd need to make use of something like ICU (icu-project.org) to keep your sanity, or implement a whole lot of that code base yourself... 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. This is about userland parts of the ramdisk. Locales don't affect the kernel. Bloat in ramdisk libc is avoided by compiling API stubs instead of the usual source files. Or some special-case #ifdef other than SMALL_KERNEL. 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, Applications don't care where a symbol comes from. Build scripts and Makefiles might expect them to be in libc and would need to link an additional library, but that's trivial to do. 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. In my opinion, if you're putting something into libc it should be a correct and functional implementation, not an API stub that doesn't really provide the advertised functionality. Libc is not a stash for missing symbols that exist on other operating systems. 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. I think you should tackle your goals (C++11, collation) in isolation. They aren't coupled, really. Later in the process I noticed there is an even smaller shim intended for Solaris as a part of libcxx, Ah. So perhaps the right approach for now is to use reuse that shim? but my thoughts were: - Locale has always been a pain in the ass, but something users demand. (or is it just me with postgresql?) You'll have to be a bit more specific about what's wrong with the current locale implementation and what user demands we don't serve. Otherwise it's hard to have a productive discussion. - Sharing this stuff with FreeBSD will make our lives easier should anything go wrong with it. Less work for us + satisfied customers. The FreeBSD collation implementation only works for characters from Latin1. It is based on code from 1995: http://svnweb.freebsd.org/base?view=revisionrevision=6485 There haven't been any functional enhancements since. If we bother with collation I think we should try to do better. - 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. Then again we must resist adding stubs to our base libraries to make 3rd party stuff happy. Otherwise the quality of base will suffer in the long term. - 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 So they're happy about their Solaris shim, but won't take an OpenBSD one? Please correct me if the philosophy is wrong. Or better, suggest other ways forward :-) Since your priorities clearly lie with C++11 and not locale support in our libc, I think you should try to make libcxx more portable. Going the other way of adding a proper xlocale implementation to libc is going to be frustrating for you if it is not a goal in itself. I would suggest to implement a small and non-OS-specific stub for libcxx that they can use on any OS lacking xlocale support. Replace/enhance the existing shim for Solaris as part of this effort. Work with the
Re: partial xlocale(3) port from FreeBSD
Indeed, doing collation properly (i.e. with Unicode, not just 8 bit characters like FreeBSD does) really is a non-trivial effort. It requires some expertise in linguistics and a solid understanding of the unicode standard. You'd need to make use of something like ICU (icu-project.org) to keep your sanity, or implement a whole lot of that code base yourself... Unfortunately, that requires support in the 3rd party software itself. Applications don't care where a symbol comes from. Build scripts and Makefiles might expect them to be in libc and would need to link an additional library, but that's trivial to do. For all such ports? Ok then :-) I think you should tackle your goals (C++11, collation) in isolation. They aren't coupled, really. Yes, but xlocale seemed like a thing they have in common. If we bother with collation I think we should try to do better. Yes, but that I think is only applying a correct library. As you've said earlier, getting this right is really hard. I would suggest to implement a small and non-OS-specific stub for libcxx that they can use on any OS lacking xlocale support. Replace/enhance the existing shim for Solaris as part of this effort. Work with the libcxx team to integrate your changes there. If they tell you that they won't run on a non-xlocale OS that isn't Solaris, implement the shim anyway and add it to our ports tree. The shim is going to be a lot less work, and doesn't preclude an implentation inside libc at a later stage. Thanks for showing the right direction. I'll look into it as soon as I have more time; at least I know what is needed and how big is it. -- Martin Pelikan
Re: partial xlocale(3) port from FreeBSD
On Mon, Oct 21, 2013 at 02:14:32PM +0200, Martin Pelikan wrote: Applications don't care where a symbol comes from. Build scripts and Makefiles might expect them to be in libc and would need to link an additional library, but that's trivial to do. For all such ports? Ok then :-) How many ports do you expect will require xlocale? I would suggest to implement a small and non-OS-specific stub for libcxx that they can use on any OS lacking xlocale support. Replace/enhance the existing shim for Solaris as part of this effort. Work with the libcxx team to integrate your changes there. If they tell you that they won't run on a non-xlocale OS that isn't Solaris, implement the shim anyway and add it to our ports tree. The shim is going to be a lot less work, and doesn't preclude an implentation inside libc at a later stage. Thanks for showing the right direction. I'll look into it as soon as I have more time; at least I know what is needed and how big is it. If xlocale is needed beyond libcxx, take a look at the misc/libutf8 port in the CVS Attic. Perhaps a port like that could serve as an API shim for xlocale until libc support for xlocale arrives. If you'd still rather do this in libc itself, e.g. because a simple shim won't provide enough functionality to make libcxx work, or because you really need it coupled up with libc locale internals, don't just copy files over from FreeBSD and make us review it all. Figure out what the steps are to get us from here to there and let us review each step. I think starting with just the locale_t data type and related functions (duplocale() etc.) on this page would be a good first step: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html This interface extension is small enough to be added in one diff, I think. I don't care if you base the implementation on FreeBSD or write your own, as long as the diff is concise and adds nicely on top what we've already got. All the clutter from new *_l() convenience functions can come later. This page provides a high-level overview of xlocale interfaces, BTW: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html That's quite a lot. I wouldn't want to add all that in one chunk.
Re: partial xlocale(3) port from FreeBSD
On Mon, Oct 21, 2013 at 02:14:32PM +0200, Martin Pelikan wrote: Indeed, doing collation properly (i.e. with Unicode, not just 8 bit characters like FreeBSD does) really is a non-trivial effort. It requires some expertise in linguistics and a solid understanding of the unicode standard. You'd need to make use of something like ICU (icu-project.org) to keep your sanity, or implement a whole lot of that code base yourself... Unfortunately, that requires support in the 3rd party software itself. Anyway, I updated to current the 8 bit collation support from FreeBSD I had sent in in March and that was reviewed by Stephan in the previous Hackathon: https://github.com/pasosdeJesus/adJ/blob/OBSD_CURRENT/arboldes/usr/src/03-cotejacion.patch Also updated the xlocale patch, also based in FreeBSD that I sent in February: https://github.com/pasosdeJesus/adJ/blob/OBSD_CURRENT/arboldes/usr/src/04-xlocale-wchar.patch https://github.com/pasosdeJesus/adJ/blob/OBSD_CURRENT/arboldes/usr/src/05-xlocale-ctype.patch https://github.com/pasosdeJesus/adJ/blob/OBSD_CURRENT/arboldes/usr/src/06-xlocale-str.patch And also updated patch for regress/lib/libc/locale/check_isw sent in March: https://github.com/pasosdeJesus/adJ/blob/OBSD_CURRENT/arboldes/usr/src/01-check_isw.patch I want to compare in detail with the implementation that Martin sent, few differences I see: * I changed the sources in order to avoid runetype.h in /usr/include * Martin implemented some pieces that I have not (e.g strtorx_l), I want to merge in what I have If we bother with collation I think we should try to do better. I agree full Unicode support is desirable, but IMHO having 8 bits collation is better than nothing (for example withouth it spanish speakers have to see ñ, á and other special symbols at the end of sorted results in programs that support collations like PostgreSQL). The shim is going to be a lot less work, and doesn't preclude an implentation inside libc at a later stage. Thanks for showing the right direction. I'll look into it as soon as I have more time; at least I know what is needed and how big is it. Since xlocale is part of POSIX shouldn't we try to include that faster in libc? I think xlocale additions to POSIX were included in the Open Group Technical Standard, 2006, Extended API Set Part 4. That is what I understand of the documentation of xlocale functions like strcoll_l, see bottom of: http://pubs.opengroup.org/onlinepubs/9699919799/functions/strcoll.html However if Martin prefers to make a new library for this, hope the patches I sent can be useful. -- Dios, gracias por tu amor infinito. -- Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/ http://www.pasosdejesus.org/dominio_publico_colombia.html
Re: partial xlocale(3) port from FreeBSD
On Mon, Oct 21, 2013 at 09:05:04AM -0500, Vladimir Támara Patiño wrote: I agree full Unicode support is desirable, but IMHO having 8 bits collation is better than nothing (for example withouth it spanish speakers have to see ñ, á and other special symbols at the end of sorted results in programs that support collations like PostgreSQL). So we add 8 bit support, and then what? Whoever would want to do it properly would have to throw the 8 bit stuff out and start all over again.
Re: partial xlocale(3) port from FreeBSD
On Sat, Oct 19, 2013 at 09:26:47PM -0700, Philip Guenther wrote:
On Tue, 15 Oct 2013, Martin Pelikan wrote:
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?
Locale support sucks because most base applications don't make use of it.
Adding more stuff to libc won't fix that.
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.
The only locale code that belongs on the ramdisks is in
/usr/src/distrib/special/libstubs/{mbrtowc_sb.c,setlocale}.c.
These are required for vfprintf(). Anything else should not
be built into the ramdisk to avoid pulling in citrus as a dependency.
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?
Re: partial xlocale(3) port from FreeBSD
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
Re: partial xlocale(3) port from FreeBSD
On Tue, 15 Oct 2013, Martin Pelikan wrote:
Apologies, I left one bit out. Here it is.
...
--- locale.h 3 Jul 2011 18:51:01 - 1.8
+++ locale.h 15 Oct 2013 19:21:31 -
@@ -54,6 +54,12 @@ struct lconv {
charn_sep_by_space;
charp_sign_posn;
charn_sign_posn;
+ charint_p_cs_precedes;
+ charint_n_cs_precedes;
+ charint_p_sep_by_space;
+ charint_n_sep_by_space;
+ charint_p_sign_posn;
+ charint_n_sign_posn;
};
No chunk for libc/locale/localeconv.c to actually set those? They'll also
need a manpage blurb. With those, this tiny chunk seems basically
harmless.
Philip
Re: partial xlocale(3) port from FreeBSD
On Tue, 15 Oct 2013, Martin Pelikan wrote:
my laptop now has libcxx working (most of the tests pass, but I haven't
checked what is missing from the C++ runtime). The steps required are:
- port xlocale(3) from FreeBSD -- this is what this patch does
Interesting: this goes beyond POSIX.2008 in many places. strtold_l()?
This stuff required for the implementation of the C++11 standard library?
Or just general random programs? Should be in the implementation
namespace either way, with weak aliases in the latter case.
- use ld(1) from binutils-2.17 to avoid linker errors (for some reason it
links symbols between first two object files and discards them for the
rest of the command line)
Can you describe the specific case where this happens? Part of linking
something against libcxxrt/libcxx?
Obviously, our locale support still sucks, this patch is mostly
providing the API for filling the blanks later.
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.
@@ -106,14 +108,14 @@ strtod
#endif
#ifdef USE_LOCALE /*{{*/
#ifdef NO_LOCALE_CACHE
- char *decimalpoint = localeconv()-decimal_point;
+ char *decimalpoint = localeconv_l(loc)-decimal_point;
int dplen = strlen(decimalpoint);
#else
char *decimalpoint;
static char *decimalpoint_cache;
static int dplen;
With threads supported, NO_LOCALE_CACHE has to be defined, no?
Index: locale/___runetype_mb.c
===
RCS file: /cvs/src/lib/libc/locale/___runetype_mb.c,v
retrieving revision 1.2
diff -u -p -r1.2 ___runetype_mb.c
--- locale/___runetype_mb.c 5 Dec 2012 23:20:00 - 1.2
+++ locale/___runetype_mb.c 15 Oct 2013 12:42:22 -
@@ -66,3 +66,4 @@ ___runetype_mb(wint_t c)
return (0U);
}
+
Heh.
Philip Guenther
Re: partial xlocale(3) port from FreeBSD
On Tue, Oct 15, 2013 at 6:40 AM, Martin Pelikan martin.peli...@gmail.com wrote: Second part (include/ headers) follows. Is this xlocale.h specified anywhere so that we can evaluate our compliance? Philip Guenther
Re: partial xlocale(3) port from FreeBSD
- port xlocale(3) from FreeBSD -- this is what this patch does I did the patch in two parts, separating include/ and lib/libc/, because my Second part (include/ headers) follows. -- Martin Pelikan Index: _ctype.h === RCS file: _ctype.h diff -N _ctype.h --- /dev/null 1 Jan 1970 00:00:00 - +++ _ctype.h15 Oct 2013 12:51:52 - @@ -0,0 +1,189 @@ +/* $OpenBSD$ */ +/* + * Copyright (c) 1989, 1993 + * The Regents of the University of California. All rights reserved. + * (c) UNIX System Laboratories, Inc. + * All or some portions of this file are derived from material licensed + * to the University of California by American Telephone and Telegraph + * Co. or Unix System Laboratories, Inc. and are reproduced herein with + * the permission of UNIX System Laboratories, Inc. + * + * This code is derived from software contributed to Berkeley by + * Paul Borman at Krystal Technologies. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * 3. Neither the name of the University nor the names of its contributors + *may be used to endorse or promote products derived from this software + *without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * From @(#)ctype.h8.4 (Berkeley) 1/21/94 + * From FreeBSD: src/include/ctype.h,v 1.27 2004/06/23 07:11:39 tjr Exp + */ + +#ifndef __CTYPE_H_ +#define__CTYPE_H_ + +#include sys/cdefs.h +#include sys/_types.h + +extern const _RuneLocale _DefaultRuneLocale; +extern const _RuneLocale *_CurrentRuneLocale; + +#define_CTYPE_A0x0100L /* Alpha */ +#define_CTYPE_C0x0200L /* Control */ +#define_CTYPE_D0x0400L /* Digit */ +#define_CTYPE_G0x0800L /* Graph */ +#define_CTYPE_L0x1000L /* Lower */ +#define_CTYPE_P0x2000L /* Punct */ +#define_CTYPE_S0x4000L /* Space */ +#define_CTYPE_U0x8000L /* Upper */ +#define_CTYPE_X0x0001L /* X digit */ +#define_CTYPE_B0x0002L /* Blank */ +#define_CTYPE_R0x0004L /* Print */ +#define_CTYPE_I0x0008L /* Ideogram */ +#define_CTYPE_T0x0010L /* Special */ +#define_CTYPE_Q0x0020L /* Phonogram */ +#define_CTYPE_SW0 0x2000L /* 0 width character */ +#define_CTYPE_SW1 0x4000L /* 1 width character */ +#define_CTYPE_SW2 0x8000L /* 2 width character */ +#define_CTYPE_SW3 0xc000L /* 3 width character */ +#define_CTYPE_SWM 0xe000L /* Mask for screen width data */ +#define_CTYPE_SWS 30 /* Bits to shift to get width */ + +/* See comments in sys/_types.h about __ct_rune_t. */ +__BEGIN_DECLS +unsigned long ___runetype(__ct_rune_t) __pure; +__ct_rune_t___tolower(__ct_rune_t) __pure; +__ct_rune_t___toupper(__ct_rune_t) __pure; +__END_DECLS + +/* + * _EXTERNALIZE_CTYPE_INLINES_ is defined in locale/nomacros.c to tell us + * to generate code for extern versions of all our inline functions. + */ +#ifdef _EXTERNALIZE_CTYPE_INLINES_ +#define_USE_CTYPE_INLINE_ +#definestatic +#define__inline +#endif + +extern int __mb_sb_limit; + +/* + * Use inline functions if we are allowed to and the compiler supports them. + */ +#if !defined(_DONT_USE_CTYPE_INLINE_) \ +(defined(_USE_CTYPE_INLINE_) ||
Re: partial xlocale(3) port from FreeBSD
- port xlocale(3) from FreeBSD -- this is what this patch does
Second part (include/ headers) follows.
Apologies, I left one bit out. Here it is.
--
Martin Pelikan
Index: locale.h
===
RCS file: /cvs/src/include/locale.h,v
retrieving revision 1.8
diff -u -p -r1.8 locale.h
--- locale.h3 Jul 2011 18:51:01 - 1.8
+++ locale.h15 Oct 2013 19:21:31 -
@@ -54,6 +54,12 @@ struct lconv {
charn_sep_by_space;
charp_sign_posn;
charn_sign_posn;
+ charint_p_cs_precedes;
+ charint_n_cs_precedes;
+ charint_p_sep_by_space;
+ charint_n_sep_by_space;
+ charint_p_sign_posn;
+ charint_n_sign_posn;
};
#ifndef NULL
