Configure question

Patrik Stridvall ps at leissner.se
Tue Nov 19 17:40:01 CST 2002


> Patrik Stridvall <ps at 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...



More information about the wine-devel mailing list