FreeBSD 3.4 support now in
Sun May 14 22:46:00 GMT 2000
This patch is is now in, regardless of my reservations:
2000-05-14 Loren J. Rittle <email@example.com>
* config/bsd/bits/ctype_base.h: Add support for plain BSD4.4.
* acinclude.m4 (GLIBCPP_CHECK_CTYPE): Enhance bsd tests.
* aclocal.m4: Regenerate.
* configure: Regenerate.
* */Makefile.in: Regenerate.
The remaining failure is going to be marked as "expected" for Free BSD 3.4.
As you've noticed, the current ctype system is kinda weak:
>However, I could also defend cloning the tree to remove the one macro
>test that I introduced and naming them config/ctype-_X-__istype-macro
>and config/ctype-_CTYPE_X-__istype-macro since that naming structure
>precisely represents what the configure test found. (Actually, I
>really like this idea, but it doesn't jive with the current
>system-based naming scheme).
Having made most of this mess, I'll say that I'm not that happy with
it either. It might be a good idea to get away from os-specific
naming, because there is much overlap. However, I've yet to find two
systems that implement this somewhat the same (except solaris 2.7 and
linux, but whatever.)
The quest for a generic ctype is impossible. The tricky parts are not
tolower and toupper (they have generic counterparts), but the is*
functions, which depend on system-specific modes (alpha, hex,
etc.). There is no way to do this generically. Thus, we punt on them.
Anyway--this whole arena is going to be unsettled, at least till
wchar_t work is finished. Please don't expend too much work trying to
make these bits more sane until then. They will be cleaned up, just
not right now....
> Aside, for maximum portability, the renamed
> newlib/bits/ctype_base.h should be fixed to use _X macros instead of
> the numeric constants. I mean, configure found the symbol constants
> so we know they exist...
Okay. Send me a patch.
More information about the Libstdc++