Re: FreeBSD 4.0

[Marc Espie <espie AT quatramaran.ens.fr>]

In article < 14810.937440488@upchuck.cygnus.com > you write:
>  In message < 37E00F41.AF49518@datadesign.com >you write:
>  > First off, I am strongly in the camp that says the fewer headers
>  > that get secreted off some place the better.  In other words,
>  > if the standard BSD compiler is GCC, then the standard BSD headers
>  > should be compatible with it.
>But, unfortunately, header requirements change over time.  This is precisely
>the problem we have had with the *BSD* systems over the years.

>Back in 1991 or so I put in a change which made GCC avoid installing its 
>own internal header files for "Net-2" systems (upon which all the *BSD variants
>are derived.

>That turned out to be a huge, unbelievably stupid, thing to do.  Why?  Because
>when we needed to provide a magic symbol (I believe in stddef.h) to ensure
>that C++ adhered to the proper definition of NULL the *BSD systems did not
>get that definition.

As far as OpenBSD goes, we are willing to fix our header files over time.
The NULL issue is now solved, and everything will be alright in that regards
for 2.6.

I'm even in the process of trying to replace (cast)(value) in the 
include files by macros that read __static_cast(cast, value).

I also would like to thoroughly annotate math functions with
__attribute__((const)) when I can. I'm still a bit unclear whether a function
that may fault with a SIGFPE, such as atan, is a good candidate for 
__attribute__((const)) or not.

>  > >From the perspective that the future will be compatible,
>That is not an assumption we can safely make because the requirements do
>change over time and GCC needs to continue to work when those requirements
>change.

As long as `new' requirements stay reasonably clear, this is not such a
large problem...  what bites is not having clear requirements, or not being
up to speed yet, as occurred for the __null issue.
In fact, this is simpler work than fixincludes, since
I am in a position to fix one set of headers without having to care about
the rest.

We can provide header archives to install with the compiler, if updates
are needed.