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. Depe
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
>
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.
* modules/getaddrinfo: Add link to openg
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 fo
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.
> * lib/getad
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
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 th
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 almos
Derek Price <[EMAIL PROTECTED]> wrote:
> Hrm. Why isn't canon-host dependant on getaddrinfo? It would simplify
> the canon-host code so much that it would probably be all right to LGPL
> it. It would also mean that canon-host could just return error codes
> suitable for gai_strerror. I'll have
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
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
don
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 <[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 worthwh
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 in
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 single-thr
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 paramete
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
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 from
18 matches
Mail list logo
