Resolving libc #includes

[Earl Chew <earl_chew at agilent dot com>]

I have a question regarding the names and locations of libc
header implementation files.

Many years ago it was not uncommon to get strange runtime
errors because your application inadvertently contained
a function like:

	struct foo read(struct db*, unsigned int entry) { ... }

causing library functions like fread() to end up calling
application code to do filesystem reads!

Recently I encountered a similar kind of issue, but this time
during compilation and involving libc headers.

Looking at some libc header files, it is common to see things
like #include <features.h>, or #include <bits/xyz.h>, etc.

It is not out of the question that application code using libc
has headers named features.h or even a subdirectory bits/ containing
file xyz.h! As you can imagine this causes all sorts of strange
error messages as libc headers end up including application source
code.

It seems to me that any #include in the libc headers means for
the header to come from the libc distribution, and not from
any old file that happens to have the correct name.

Do any of the standards speak to this kind of problem?

Should libc be more robust in this regard, and how so?

Earl