> > #include <limits.h> > > If the C file were including headers that in turn included limits.h, > this problem could not be occurring. So there's no point grepping > around for it.
Sometimes the code will have #ifdefs which are expected to be passed in / controlled by the build engine. If the build engine does not deal with the target platform correctly, the logic becomes incorrect and the appropriate header file does not get included. > To be more specific, the header should be included by the file that > references its contents. So if PATH_MAX is being used in foo.h, then > foo.h should have the above #include; if it's being used in H5Fint.c, > then H5Fint.c should have the #include, etc. Adding more includes to > random headers is not preferred at all; there is a simple and specific > way to tell what file should be including the header. That is a very contentious statement: I have had arguments over this with developers wanting me to perform their port work for them, which ended up with having to edit hundreds of files to #include the missing header file in question, when all that was needed was to include it in the top level header which all those files were including. The colleague in question objected very strongly to including it into the top level header under the pretense that it would slow the build down, which I vehemently disagreed with, since that is easily resolved with the following construct: #ifndef PATH_MAX #include <limits.h> #endf ...causing the preprocessor to process it once and only once. "13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time." http://www.faqs.org/docs/artu/ch01s06.html#id2878666 ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
