[Nut-upsdev] Re: [nut-commits] svn commit r708 - in trunk: . clients server

[Arjen de Korte]

> With the Ipv6 patch (r708), I get:
>
> upsclient.c: In function `upscli_connect':
> upsclient.c:469: `AI_ADDRCONFIG' undeclared (first use in this function)
> upsclient.c:469: (Each undeclared identifier is reported only once
> upsclient.c:469: for each function it appears in.)

I got a report from Doug about similar problems in 'server/access.c'. It
builds cleanly on my openSUSE 10.2 system however, so this looks like a
portability problem.

> Even if it doesn't break IPv4 support, it may break portability, as
> IPv6 seems to require specific functions that are not as standardized
> as the IPv4 ones. For example it uses "struct addrinfo" and not
> "struct sockaddr_in". Moreover, it seems that my version of
> getaddrinfo() recognizes different flags than this patch assumes.

Point taken.

> Ideally the availability of IPv6 functions should be detected at
> configuration time. Unfortunately, the patch uses the new interface
> even for IPv4 support, so there is no easy way of enclosing the
> non-portable stuff in #ifdef's.

I think if possible it is better to use one interface for both eventually.
However, as you already indicated, it looks like the library functions
involved are far from stable enough to be of general use now, so until
that is the case, the old code should be the default.

> Perhaps it would be better to develop this patch in a branch, and
> reverse the commit on the main branch until the portability issues are
> resolved? The ideal situation would be to enclose all the IPv6 stuff
> in #ifdef's, and leave the IPv4 stuff as it was before.

I prefer to keep it in the trunk, but enclosed in #ifdef's and hopefully
with some kind of autodetection stuff to determine whether it is safe or
not to use it. We should get as much feedback as possible on this, which
is not going to happen if we put it on a sidetrack in branches (sadly
enough, because there are a couple of nice developments there). I'll bring
back the 'old' IPv4 stuff later today with #ifdef'ing to make the IPv6
code available.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57