Bug #67944 for Socket-GetAddrInfo: AI_ADDRCONFIG and other constants missing from Socket::GetAddrInfo

Wed May 04 16:07:30 2011 ambrus [...] math.bme.hu - Ticket created

Subject:

AI_ADDRCONFIG and other constants missing from Socket::GetAddrInfo

Dear Socket-GetAddrInfo maintainers, There are some constants that can be used with the getaddrinfo or getnameinfo functions, but are not exported by the Socket-GetAddrInfo-0.21 module. All of these seem to exist or are documented for at least one of GNU libc and OpenBSD libc. I believe that the module should export these if the libc of the system supports them. Please change the module to do it, and please do the same changes on the Socket module if necessary. Don't forget to #define _GNU_SOURCE and similar if you want to get all these constants. Following is the list of such constants I'd like, with a brief synopsis of what they do (these do not mean to be complete descriptions). flags for the flags element of the hints argument of getaddrinfo. AI_V4MAPPED allow to return ipv6-mapped ipv4 addresses as fallback if ipv6 requested. AI_ALL return ipv6-mapped ipv4 addresses too if AI_V4MAPPED also set. AI_ADDRCONFIG use only address families configured on this machine. AI_IDN encode non-ascii domain names. AI_CANONIDN decode returned non-ascii domain names. AI_IDN_ALLOW_UNASSIGNED see docs. AI_IDN_USE_STD3_ASCII_RULES see docs. flags for the flags argument of getnameinfo. NI_NOFQDN return only hostname part for hosts on local domain. NI_IDN decode returned non-ascii domain names. NI_IDN_ALLOW_UNASSIGNED see docs. NI_IDN_USE_STD3_ASCII_RULES see docs. error codes returned by getaddrinfo and/or getnameinfo. EAI_SYSTEM system error, check errno for details. EAI_OVERFLOW output buffers passed to getnameinfo too small (this probably shouldn't happen with the perl interface though). EAI_BADHINTS bad hints value -- the OpenBSD manpage lists it. EAI_PROTOCOL "resolved protocol is unknown", whatever that means -- again, from OpenBSD (there are a few more error codes in the glibc header but I don't see them documented and they're probably only relevant with nonblocking name resolver) In case it matters, I am using Socket-GetAddrInfo-0.21 with perl 5.12.3 vanilla on an amd64-linux system. Ambrus

Wed May 18 11:36:53 2011 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Wed May 04 16:07:30 2011, ambrus@math.bme.hu wrote: Show quoted text

> There are some constants that can be used with the getaddrinfo or > getnameinfo functions, but are not exported by the > Socket-GetAddrInfo-0.21 module. All of these seem to exist or are > documented for at least one of GNU libc and OpenBSD libc.

Hi there. Hmmm. This is sortof a tricky issue, really. On the one hand, Socket::GetAddrInfo tries to export a Perl wrapper around the real functions in libc, but on the other it also tries to be a pureperl emulation using only the legacy resolvers, in cases where the underlying OS cannot support it. I could very easily add wrappers for all these constants to the GetAddrInfo.xs file, that's not too hard. But some of them would be doing things that the pureperl emulations cannot represent. For example, it wouldn't be possible to implement AI_ADDRCONFIG, or most of the IDN support. So I'm left with a dilema here: a: Wrap these constants only at the XS level, and not at all at the pureperl level b: Wrap them at the XS level, provide dummy values at the PP level, but instantly fail if people try to use them in a real getaddrinfo() call c: Do not wrap them at all Given the relatively rare case of a system that can't, actually, support getaddrinfo, I don't feel it's justified to not wrap them at all. I'm tempted to suggest either a or b. Both would allow a program to be written and run successfully on machines that do support the flags. They differ slightly in their handling in the case where the machine does not support them. This needs some more consideration... -- Paul Evans

Wed May 18 11:36:54 2011 The RT System itself - Status changed from 'new' to 'open'

Thu Nov 10 07:06:36 2011 leonerd-cpan [...] leonerd.org.uk - Dependency by ticket #72338 added

Thu Nov 10 11:10:51 2011 leonerd-cpan [...] leonerd.org.uk - Correspondence added

I've just CPAN'ed 0.21_001, which aims to provide these missing constants. 0.21_001 CHANGES: * Move most exports into @EXPORT_OK * Provide exception-throwing version of API in Socket::GetAddrInfo::Strict * Wrap lots more flag constants + AI_IDN, AI_V4MAPPED, AI_ALL, AI_ADDRCONFIG + NI_IDN, NI_NOFQDN + EAI_SYSTEM, EAI_BADHINTS, EAI_PROTOCOL If this appears to build reliably across a variety of architectures I'll call it 0.22 -- Paul Evans

Thu Nov 10 11:10:53 2011 leonerd-cpan [...] leonerd.org.uk - Status changed from 'open' to 'patched'

Wed Feb 08 09:39:38 2012 leonerd-cpan [...] leonerd.org.uk - Dependency by ticket #72338 deleted

Sat Jun 02 11:36:44 2012 leonerd-cpan [...] leonerd.org.uk - Correspondence added

Released as 0.22. -- Paul Evans

Sat Jun 02 11:36:44 2012 The RT System itself - Status changed from 'patched' to 'open'

Sat Jun 02 11:36:45 2012 leonerd-cpan [...] leonerd.org.uk - Status changed from 'open' to 'resolved'

Sat Jun 02 11:36:57 2012 leonerd-cpan [...] leonerd.org.uk - Fixed in 0.21_001 added

Sat Jun 02 11:36:57 2012 leonerd-cpan [...] leonerd.org.uk - Fixed in 0.22 added