User-configurable UCLIBC_HAS_CTYPE_TABLES Make toupper etc work thru translation tables and isalhum etc thru lookup tables. Help says: "While the non-table versions are often smaller when building statically linked apps, they work only in stub locale mode." "stub locale mode" is when !UCLIBC_HAS_LOCALE I presume, when we are permanently in POSIX/C locale. UCLIBC_HAS_CTYPE_SIGNED Handle sign-extended chars. I.e. if you want toupper((char)0xa0) => toupper(0xffffffa0) => still works correctly, as if toupper(0xa0) was called. UCLIBC_HAS_CTYPE_UNSAFE/CHECKED/ENFORCED Do not check ctype function argument's range/check it and return error/check it and abort(). Help says: NOTE: This only affects the 'ctype' _functions_. It does not affect the macro implementations. [so what happens to macros?] [examples?] UCLIBC_HAS_WCHAR Wide character support. I assume all those wchar_t types and functions UCLIBC_HAS_LOCALE/XLOCALE Support locale / extended locale UCLIBC_PREGENERATED_LOCALE_DATA Not recommended uclibc internal machinery __LOCALE_C_ONLY #defined if !UCLIBC_HAS_LOCALE __NO_CTYPE #defined only by some .c files. Prevents ctype macros to be #defined (those w/o underscores. __ctype() macros will still be defined). Looks like user is expected to never mess with defining it. __UCLIBC_DO_XLOCALE #defined only by some .c files. Looks like user is expected to never mess with defining it. __XL_NPP(N) - "add _l suffix if locale support is on" #defined to N ## _l if __UCLIBC_HAS_XLOCALE__ && __UCLIBC_DO_XLOCALE, else #defined to just N. __CTYPE_HAS_8_BIT_LOCALES __CTYPE_HAS_UTF_8_LOCALES Depends on contents of extra/locale/LOCALES data file. Looks like both will be set if UCLIBC_HAS_LOCALE and extra/locale/LOCALES is not edited. __WCHAR_ENABLED locale_mmap.h defines it unconditionally, extra/locale/gen_ldc.c defines it too with a warning, and _then_ includes locale_mmap.h. Makefile seems to prevent the warning in gen_ldc.c: ifeq ($(UCLIBC_HAS_WCHAR),y) BUILD_CFLAGS-gen_wc8bit += -DDO_WIDE_CHAR=1 BUILD_CFLAGS-gen_ldc += -D__WCHAR_ENABLED=1 endif A mess. Why they can't just use __UCLIBC_HAS_WCHAR__? __WCHAR_REPLACEMENT_CHAR Never defined (dead code???) Actual ctype macros are a bloody mess! __C_isspace(c), __C_tolower(c) et al Defined in bits/uClibc_ctype.h. Non-locale-aware, unsafe wrt multiple-evaluation, macros. Return unsigned int. __isspace(c), __tolower(c) et al Defined in bits/uClibc_ctype.h. Non-locale-aware, but safe wrt multiple-evaluation, macros. Return int. __isdigit_char, __isdigit_int Visible only to uclibc code. ((unsigned char/int)((c) - '0') <= 9). _tolower(c), _toupper(c) Even more unsafe versions (they just do | 0x20 or ^ 0x20). Sheesh. They are mandated by POSIX so we must have them defined, but I removed all uses in uclibc code. Half of them were buggy. isspace(c), tolower(c) et al Declared as int isXXXX(int c) in bits/uClibc_ctype.h. Then, if not C++ compile, defined as macros to __usXXXX(c) bits/uClibc_ctype.h is included by ctype.h only if !__UCLIBC_HAS_CTYPE_TABLES__. Otherwise, ctype.h declares int isXXXX(int c) functions, then defines macros for isXXXX(c), __isXXX(c), toXXXX(c). Surprisingly, there are no __toXXXX(c), but if __USE_EXTERN_INLINES, there are inlines (yes, not macros!) for toXXXX(c) functions, so those may have both inlines and macros!). It also defines "unsafe" _toXXXX macros. All in all, __isXXXX(c) and __toXXXXX(c) seem to be useless, they are full equivalents to non-underscored versions. Remove? Macro-ization of isXXX(c) for __UCLIBC_HAS_XLOCALE__ case is problematic: it is done by indexing: __UCLIBC_CTYPE_B[c], and in __UCLIBC_HAS_XLOCALE__ case __UCLIBC_CTYPE_B is doing a __ctype_b_loc() call! We do not save function call! Thus, why not have dedicated optimized functions for each isXXXX() instead? Looking deeper, __ctype_b_loc() may have another lever of function calls inside! What a mess...