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
2005-09-04 Derek Price [EMAIL PROTECTED]
* gnulib-tool: Fix reversed $symbolic logic.
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]
Index: gnulib-tool
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
Martin Lambers [EMAIL PROTECTED] writes:
Hi!
I think the size_max module misses the Makefile.am entry
lib_SOURCES += size_max.h:
$ ./gnulib-tool --create-testdir --dir=/tmp/t size_max
$ cd /tmp/t
$ ./configure
$ make dist
The resulting tarball does not contain size_max.h.
The
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
Compiling getopt.c I get these warnings from gcc:
getopt.c: In function `_getopt_initialize':
getopt.c:253: warning: unused parameter `argc'
getopt.c:253: warning: unused parameter `argv'
getopt.c:1159:5: warning: _LIBC is not defined
While harmless I think they could be removed by
14 matches
Mail list logo
