[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev still problems with h_errno
From: |
Klaus Weide |
Subject: |
Re: lynx-dev still problems with h_errno |
Date: |
Thu, 18 Mar 1999 16:46:05 -0600 (CST) |
On Thu, 18 Mar 1999, Bela Lubkin wrote:
> Tom Dickey wrote:
>
> Bela>> I'm not familiar with the detailed operation of autoconfig, but what I
> Bela>> think is wanted here is approximately:
> Bela>>
> Bela>> is h_errno already declared by one of the headers included by
> HTTCP.c?
> Bela>> -- then do nothing
> Bela>> otherwise, is h_errno declared if we #include <resolv.h>?
> Bela>> -- then #include <resolv.h> in HTTCP.c
> Bela>> otherwise,
> Bela>> -- declare "extern int h_errno;" in HTTCP.c
>
> Tom> not only that: does h_errno exist in the library.
>
> You could check for that, but I don't think it's necessary. The code
> we're trying to compile depends on a lot of other intimate details of
> the BIND resolver library; it wouldn't work with any other
> implementation.
It depends just on
struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses */
}
#define h_addr h_addr_list[0]
which is a struct that has to be there for *any* system with gethostbyname().
It doesn't refer to any more intimate details (for example
extern struct state _res;
int res_init(void);
int res_query(const char *dname, int class, int type,
unsigned char *answer, int anslen);
and so on), besides assuming that h_errno is available. It's actually
also used for Windows (for TRACE output only) in
#ifdef DEBUG_HOSTENT
dump_hostent("End of LYGetHostByName", result_phost);
CTRACE(tfp, "LYGetHostByName: Resolved name to a hostent.\n");
#endif
and we would have heard of problems with Windows by now if this was
a problem... (It's been there since dev.16.) This section is also
done for Windows:
if (!valid_hostname(host)) {
lynx_nsl_status = HT_NOT_ACCEPTABLE;
h_errno = NO_RECOVERY;
so it seems the Winsock header files also define h_errno and NO_RECOVERY.
> And I believe BIND has had h_errno as long as the
> library has existed. The only dangerously variable part is where (and
> whether) you can pick up a header file which conveniently declares it
> for you, instead of having to extern it yourself.
>
> i.e. the #ifdefs that already omit that code on other platforms, like
> Windows, should exactly match the subset of systems which have h_errno.
Only DJGPP is excluded from all the fun; Windows doesn't seem to have
a problem afaik (not that I have tested it, but it seems there were
binaries packaged since then).
Btw. I haven't forgotten your comments on the changes...
Klaus