FreeBSD 4.0 support now in

Loren James Rittle
Thu May 11 00:32:00 GMT 2000

In article < >,
Benjamin Kosnik <> writes:

>> The reason is that _A, etc were changed to _CTYPE_A, etc on the 4.0
>> branch to help alleviate problems with C++ headers. ;-)

> Ha ha. 

> freebsd4.0 (bsd4.4?)
> freebsd3.4 (bsd4.3?)

See below.

> I don't understand the bsd naming conventions, so perhaps you can explain 
> the bizarre naming schemes between openBSD, freeBSD, BSD, etc.

I really can't explain the current naming mess (other than the
obvious: it directly represents code/project goal/personality conflict
forking) with any authority.  With the help of chapter 1 of _The
Design and Implementation of the 4.4BSD Operating System_ book, I can
explain how the versions relate.

The following is the release line from Berkeley:

4.3BSD -> 4.3BSD-Tahoe -> 4.3BSD-NET/1 (not complete system) -> 4.3BSD-Reno ->
4.3BSD-NET/2 (not complete system) -> 4.4BSD -> 4.4BSD-Lite1 -> 4.4BSD-Lite2

386BSD took 4.3BSD-NET/2 and added what was required to make a
runnable system on the i386.

NetBSD effectively broke off the Berkeley line at 4.3BSD-NET/2 via
386BSD with almost all changes merged from 4.4BSD-Lite1 and
4.4BSD-Lite2 (but for reasons unknown to me, none related to ctype.h
and some other user-space headers) with the goal of wide portability.

OpenBSD broke off NetBSD at some point with the goal of enhancing
security (this authoritative book doesn't cover that split).

FreeBSD 1.0 broke off the same point that NetBSD did.  However,
FreeBSD 2.0 and later is based upon 4.4BSD-Lite-1 instead of being
continued from FreeBSD 1.0 with changes merged from 4.4BSD-Lite-2.

Aside: I think the above short, convolved history explains why
configure's approach to finding OS capabilities instead of using
professed version numbers is a great thing.

> I any case, it looks like you can duck around this as the only file that
> differs is ctype_base.h. In that case, the macro type solution you 
> proposed is probably best.


> let's adopt a consistent naming scheme for the versions, ok? This will 
> require your input.... i would prefer to base off of the BSD4.x version 
> numbers, not free/open/whatever BSD numbering.

I fully agree with your goal of using a consistent naming scheme.
Here is my "easy" recommendation:

Since it is my belief that (a) almost zero people running pre-4.3BSD
systems care about upgrading gcc (which for all I know works anyway -
in any event I don't know how that ctype.h might look different than
4.3); and (b) config/newlib appears to support 4.3BSD-style ctype.h.
Your original choice of config/bsd isn't bad.  I.e. please apply my
last patch, we are done with the issue.

Taking the goal to its logical extreme, here is the "harder"

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

We could then rename config/newlib to config/ctype-_X-_ctype_-table
since that too directly describes the implementation found by
configure.  Assuming the configure check is robust enough, it is
irrelevant exactly what OS or library implementation it found the
construct on.  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...

As another example, for solaris we could use:
# I admit don't understand the full subtly of the test between 2.6 and 2.7

Aside, config/generic is still somewhat buggy.  It appears to assume
that some sort of table-driven approach is under-the-hood of libc and
that it can find that table.  I think it should be possible to build
and run (at some slower speed perhaps) on any architecture that
supports the standard ANSI C macros/functions interface even where
configure found a better tree to use.  If the run-time is similar on
common architectures, we could question why we want any of this
configure hackery.

I was already going to try to fix the config/generic tree as I outline
above before you made a new config/bsd.  I will commit to providing a
patch to configure and the config directory structure (at least for
the three obviously BSD-style configurations - I include newlib here
since that library interface tries to adhere to 4.3BSD's libc more or
less), if you decide that approach makes any sense.

>> + #ifdef _CTYPE_S

> isn't there some other macro you can use that relates to the actual BSD 
> version number.......

To my knowledge, there is no macro that is respected by all the
various branches of BSD.  They all believe themselves to be the last
greatest hope for BSDism. ;-)

FreeBSD does have a version number macro (I think it changes daily so
very fine header file changes can be assumed based on the exact
value), but on the chance that other BSDs adopt the longer ctype-flag
macros, we shouldn't use it.  Keying off anything BSD version specific
has caused many maintenance problems in gcc/ginclude/std*.h.

In this case, even with the above said, I would like to defend my
choice of macro to key off here.  This is one of the exact symbols
that configure tested for.  Shouldn't that be used over any random
version number that was not checked in configure?  The TAO of
configure says that you test for properties of the OS not the version


More information about the Libstdc++ mailing list