Daniel Reed <n@xxxxxx> writes: > My point is that an interface can be written that depends on a > particular environment, being a set of requirements. In fact, all > interface headers depend on particular environments to some degree: My > contention is that the scope of the environment need not be a lowest > common denominator of all underlying system environments out there. > Whenever an interface uses the type "void" it is relying on a > non-guaranteed (non-universal) aspect of its environment. Personally, I've found that most of these sorts of problems have actually gone away. The really difficult bits of config.h to deal with as an installed header file for me are the ones that define or undefine standard C keywords for portability to older systems, and I've stopped needing that for current software. In practice, const is implemented universally now. In practice, void is implemented universally now. There are only a very small number of software packages that actually need that degree of portability (although there are a much larger set of software packages that give lip service to it but wouldn't actually work on a system missing const or void for entirely different reasons). It may be that this is just cyclical, and in a few more years we'll all be dealing with the same issue for "restrict" and the like, but at least for right now I tend to only have to use the HAVE_* defines, which are far, far easier to deal with. -- Russ Allbery (rra@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/> _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
