Re: FreeBSD 3.4 support now in

[Benjamin Kosnik <bkoz at cygnus dot com>]

Loren:

This patch is is now in, regardless of my reservations:

2000-05-14  Loren J. Rittle  <ljrittle@acm.org>

        * 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).

Duly noted.

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.

Thanks again,
-benjamin