compiler warnings in getopt.c

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 ad

Re: canon-host errors

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

Re: canon-host errors

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

Re: canon-host errors

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

Re: canon-host errors

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

Re: canon-host errors

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

Re: size_max module: missing Makefile.am entry

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.

Re: canon-host errors

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

FYI: gnulib-tool reverse --symlink logic fix

2005-09-04 Derek Price <[EMAIL PROTECTED]> * gnulib-tool: Fix reversed $symbolic logic. Regards, Derek -- Derek R. Price CVS Solutions Architect Ximbiot v: +1 717.579.6168 f: +1 717.234.3125 Index: gnulib-tool ==

Re: canon-host errors

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

Re: canon-host errors

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

Re: canon-host errors

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

Re: canon-host errors

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

Re: canon-host errors

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

canon-host errors

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