Conventions for system headers

[Maciej Sobczak]

Bruce Evans wrote:

>> http://www.freebsd.org/cgi/man.cgi?query=if_nametoindex
> 
> That is a bug in if_indextoname.3.

What about IEEE Std. 1003.1? Does it have a bug as well?

>> But in reality <net/if.h> is not complete.
> 
> Network headers generally have intricate, poorly documented, but very
> "BSD-standard" prerequisites

Still, they seem to be breaking current standards.
Is BSD heritage valued more?

>>> Generally try to avoid namespace pollution
>>
>> Interestingly, namespace pollution cannot get worse by solving this 
>> problem - it can even be potentially reduced.
> 
> Yes, but reducing it is difficult.

Sure. That's why I would propose the "easy fix" first.

> [...] if Y.h is included in X.h, then the programmer has to read the or
> remember the documentation to know what is included, and the documentation
> has to be correct.

That's right.

> In practice, the documentation is rarely correct

Indeed. ;-)

What about creating a script/tool/whatever that will make such a 
documentation automagically? Surely, this is a good candidate for 
automation?

>> A simple fix, just to keep the convention that allows arbitrary order, 
>> is to #include Y.h from X.h. This way X.h becomes complete - but the 
>> namespace pollution does not increase; in fact, the sequence of tokens 
>> that the compiler sees is exactly the same. It is just more convenient 
>> for the user and consistent with the standards.
> 
> It is a bug for standard to allow this

Why? Can you give some references?
The C++ standard explicitly allows headers to #include other standard 
headers. I cannot find anything in the C standard that would forbid it.

In any case, POSIX requires that <net/if.h> is complete.

>> I would like to propose to fix the problem the simple way (for the 
>> moment) - by just forcibly #include'ing the required headers from 
>> their dependants. It will not lead to proliferation of new headers and 
>> the namespace pollution will remain the same as it is now.
> 
> I think this would result in namespace pollution soon growing much larger,
> since it removes a limit on pullution for new interfaces.

I still don't understand this argument about pollution - if the header 
is incomplete, then the user has to "pollute" his namespace on his own. 
Anyway.

Regards,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/