> Patrik Stridvall <[EMAIL PROTECTED]> writes: > > > Still I think the code should verify that any assumptions > > made str really true, if possible. Like: > > > > #if defined(HAVE_GETPWUID) || defined(HAVE_GETPWNAM) || > > defined(HAVE_GETPWENT) > > # if !(defined(HAVE_GETPWUID) && defined(HAVE_GETPWNAM) && > > defined(HAVE_GETPWENT)) > > # error All or none of the functions getpwuid, getpwnam > and getpwent are > > assumed to exist > > # endif > > #endif > > There is absolutely no reason to do that, because we shouldn't assume > anything like that. As I said, if you use getpwnam() you check for > HAVE_GETPWNAM; whether getpwuid() also exists or not is completely > irrelevant.
Well, the problem is it is possible that you in order to fail gracefully needs to do different things depending on whether some other function exists or not. OK, the functions meantioned above are not likely to have side effect or something else that effect the other functions in any relevant way. But there might be function pairs, tripples etc that does. Sure you can say that since any function might fail any code should always be able to handle a missing function as well since it in some abstract meaning it sufficiently similar to a normal failure. But regardless, I think it is good to make it clear that he or she who wrote expects certain things to be true and things might not work if they are not true. I somebody hits the "assertion" they can audit the code and if it seems that it doesn't matter they can modify the "assertion" to whatever is proper in the light of the new different enviroment. If it does matter they will modify the code accordingly... Somehow this seems much better than just hoping that the orginal programmer handled all error cases correctly...