Derek Price [EMAIL PROTECTED] wrote:
I've installed the attached patch. It is almost identical to my
previous one, with a few extra portability and typo fixes.
2005-09-12 Derek Price [EMAIL PROTECTED]
* modules/canon-host: Add canon-host.h. Depend on getaddrinfo. Make
LGPL.
Jim Meyering wrote:
Derek Price [EMAIL PROTECTED] wrote:
I've installed the attached patch. It is almost identical to my
previous one, with a few extra portability and typo fixes.
2005-09-12 Derek Price [EMAIL PROTECTED]
* modules/canon-host: Add canon-host.h. Depend on getaddrinfo.
Is there any reason I can't just assume gl_GETADDRINFO ran and config.h
was included before getaddrinfo.h? The following test is always coming
up false on platforms without getaddrinfo (as of AC 2.59, at least,
AC_CHECK_FUNCS via AC_REPLACE_FUNCS leaves HAVE_GETADDRINFO undefined
when it is not
Derek Price [EMAIL PROTECTED] writes:
* modules/getaddrinfo: Add link to opengroup spec. Depend on strdup.
Make canon-host require getaddrinfo.
* m4/getaddrinfo.m4 (gl_GETADDRINFO): Compile gai_strerror when needed.
Return usable errors from canon-host.
*
Jim Meyering wrote:
suitable for gai_strerror. I'll have to extend lib/getaddrinfo.c a
little to fill in ai_canonhost and add the gai_strerror function. Would
that be acceptable?
Good idea. More than `acceptable' :-)
Patch attached. I decided the reverse-lookup which used to be
Hi all,
Would anyone object to a patch that caused canon-host to output warnings
via error (0, ...) when one of the functions it calls fails?
getaddrinfo returns errors differently than gethostbyname and
gethostbyaddr, making outputting a useful error message upon seeing a
simple NULL return
Derek Price [EMAIL PROTECTED] wrote:
Would anyone object to a patch that caused canon-host to output warnings
via error (0, ...) when one of the functions it calls fails?
getaddrinfo returns errors differently than gethostbyname and
gethostbyaddr, making outputting a useful error message upon
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
Jim Meyering wrote:
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?
Okay. Will do. Should I ignore single-threaded apps entirely, keep the
error data in a global to simplify for
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
Derek Price [EMAIL PROTECTED] wrote:
Okay. Will do. Should I ignore single-threaded apps entirely, keep the
error data in a global to simplify for single-threaded apps on NULL, or
break the functions into canon_host, canon_host_r, strcherror,
strcherror_r?
I don't thinks it's worthwhile to
Jim Meyering wrote:
I don't thinks it's worthwhile to pander to single-threaded
applications for something like this.
In this case, pandering isn't very complicated, so I think I'll do it.
Besides, this way, if anyone else is using the canon-host module, they
won't need to update callers
Derek Price wrote:
Hrm. Why isn't canon-host dependant on getaddrinfo? It would
The alternative is that the ch_strerror_r function I've been working on
would need to handle ENOMEM too, which introduces a dependency on
strerror_r... I almost have the previously discussed canon-host code
done
Derek Price wrote:
This was about what I was thinking, though I was going to combine
canon_host canon_host_r in the canon-host module and let the caller
decide what to call. How about this API:
Hrm. Why isn't canon-host dependant on getaddrinfo? It would simplify
the canon-host code so
Derek Price [EMAIL PROTECTED] wrote:
Derek Price wrote:
Hrm. Why isn't canon-host dependant on getaddrinfo? It would
The alternative is that the ch_strerror_r function I've been working on
would need to handle ENOMEM too, which introduces a dependency on
strerror_r... I almost have the
Hrm. The POSIX getaddrinfo specification is pretty clear about *not*
resolving a name for ai_canonname if name is in IP dot notation, yet
sometimes the canon-host implemetation does a reverse-lookup to get a
canonical name (for some odd condition where gethostbyname fills in the
h_name field of
16 matches
Mail list logo
