David O'Brien wrote:
>
> Hi Bruce,
>
> Can you explain why fixinc needs to do this change of stdlib.h?
>
> Also why GCC needs to install its own version of assert.h?
> What is wrong with the base one?
Obviously, nothing is really wrong with any of these files.
The real question is, "Why is fixincl fixing files that ain't broke?"
Fundamentally, the problem is is that the header files, as a
whole, are a joint domain of the compiler and the OS. Some compiler
vendors solve the problem by shipping their own headers for every
approved target system. That was deemed inconvenient for GCC.
Systems vendors ship headers that play well with their own compiler.
GCC isn't a system vendor, either. So, GCC fixes the native headers
so that it can do its job and it can emit code that talks to the local
OS. This does not answer your question, but it sets the stage and
it explains why it is appropriate for GCC to diddle with headers
that are used for its own purposes.
In the open source OS environment, the headers are generally
properly formed. For one thing, they uniformly use GCC as the
system compiler, so there is extra incentive to make the headers
GCC-friendly. But that is only "generally" true. Buggy headers
*have* been released. Furthermore, what were not bugs before
have become bugs now, and what are not now bugs may become so
in the future. So, GCC cannot blindly rely on correct headers,
even for open source OSes.
But why fix it if it is not broken? Because fixincludes could not
tell that it was not broken. Fixincludes is a compromise between
total processing time for all users, wasted disk space and available
programmer time for putting smarts into it. It is pretty much
restricted to regular expression pattern processing, but you are more
than welcome to write additional methods. They will plug into the
system fairly seamlessly. See "fixfixes.c", "fixtests.c" and "README"
in the gcc/fixinc directory for more information.
So, if you want fixincludes to stop fixing unbroken headers,
*please* feel free and even encouraged to submit patches.
Thank you.
Regards,
Bruce
P.S. Does anyone think we can hack this into an appropriate FAQ?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
