In message <[EMAIL PROTECTED]>,
Thomas David Rivers <[EMAIL PROTECTED]> wrote:
rfg> Here is a list of a few system include file problems, in no particular
rfg> order. Most of these are ANSI conformance problems.
rfg> ... {bugz elided} ...
> This begs a question.... and to help in my understanding...
>
> Certainly, these header files aren't ANSI conforming.
That is correct.
> But - that's not to say we don't have an ANSI conforming C implementation,
That is also correct.
> as these aren't ANSI header files - right?
Right. Those are not header files that are mandated by the ANSI C standard
and thus, the ANSI C standard also does not mandate that they be conformant
with the standard before you can claim that you have a conforming ANSI C
implementation.
> That is; isn't it true that in our "own" header files - we can do whatever
> we want?
You're talking about the difference between the strict letter of the law,
and pragmatic usefulness.
Yes, according to the strict letter of the law, all of these other system
include files don't even have to exist, and if they do exist, they could
contain any garbage you want, including random binary bytes that drive the
compiler absolutely mad. The ANSI C standard has _nothing_ to say about
any system include files _except_ the very limited set that the ANSI C
standard actually mandates and talks about.
But pragmatically, it sure would be nice if I (or you) as a programmer
developing stuff on FreeBSD could include various of the FreeBSD include
files into any program that we happen to be working on, and then fire up
the compiler (with our own personal favorite set of command line options)
and then _not_ be plagued by a whole bunch of spurious warnings and/or
errors that have noting actually to do with _our_ code.
This isn't about standards conformance. It is about providing a top
quality _complete_ software developement system/environment.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
