Patrik Stridvall ps@leissner.se 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...