Derek Price <[EMAIL PROTECTED]> wrote: > Hrm. A new enum parameter would mean duplicating a bunch of potential > POSIX error codes from the other three functions. How about if I leave > the enum parameter somewhat opaque and provide a canon_host_error > (perhaps strcherror is a better name) to interpret it and print the > error if desired? > > I'd really prefer to leave the error as opaque as possible, even to the > canon_host & strcherror functions.
That sounds fine. > Is there any convenient yet portable > way I could merge the two sets of error codes into one range of values? > Shifting one set left 16 bits? > > Maybe the most straightforward way to go about it is simply to return > the error as two values, an enum with values like CH_NO_ERROR, > CH_EAI_ERROR, & CH_HERROR, plus an int which either holds the return > code from getaddrinfo or the value of h_error upon return from > gethostbyname or gethostbyaddr (and is undefined on success)? Then > strcherror & canon-host would have protos like: > > char *strcherror (enum canon_error errtype, int errcode); > char *canon_host (char *hostname, enum canon_error *errtype, int > *errcode); > > Callers not interested in the error codes could pass NULL in for errtype > & errcode. Could probably even add CH_USE_GLOBAL to the enum and keep > the last error encountered in a static global for single-threaded apps, > but maybe that is overkill? I like your idea of keeping them separate. How about passing either NULL or the address of a struct containing a member for each error indicator? _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib