Jim Meyering wrote: >Personally, I don't mind if you add the code to emit warnings now, >as long as you agree to adjust the API later, (e.g., to add >a new enum parameter describing the error) if anyone complains. >Of course, it'd be better to keep it library-safe. > >
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. 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? Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot <http://ximbiot.com> v: +1 717.579.6168 f: +1 717.234.3125 <mailto:[EMAIL PROTECTED]> _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib