getaddrinfo() AI_IDN feature test

[Mike Frysinger]

On 09 Mar 2015 19:16, Martin Lambers wrote:
> On Mon, 9 Mar 2015 13:30:55 -0400, Mike Frysinger wrote:
> > On 09 Mar 2015 09:58, Martin Lambers wrote:
> > > On Sun, 8 Mar 2015 09:29:14 -0400, Mike Frysinger wrote:
> > > > On 01 Jan 2015 08:03, Martin Lambers wrote:
> > > > > I recently changed two programs to use the AI_IDN flag for
> > > > > getaddrinfo() instead of using libidn.
> > > > > 
> > > > > Users reported runtime failure (EAI_BADFLAGS) on systems where
> > > > > glibc was build without libidn support.
> > > > > 
> > > > > On these systems, AI_IDN was defined nevertheless -- is this
> > > > > intended behaviour? If so, then #ifdef AI_IDN is not enough;
> > > > > what is the recommended way to check if AI_IDN actually works?
> > > > 
> > > > what version of glibc exactly ?  my reading of the git history is
> > > > that since AI_IDN was added to the header for 2.4, glibc has
> > > > unconditionally supported it.
> > > 
> > > The glibc as shipped with AstLinux <http://www.astlinux.org>. I do
> > > not have more information. Yes, AI_IDN is added unconditionally,
> > > but it is only actually accepted when glibc is compiled with
> > > libidn. See glibc-2.21/sysdeps/posix/getaddrinfo.c lines 2344-2347.
> > 
> > yes, but if you trace back the code, you'll see that:
> > (1) libidn is always bundled with glibc
> > (2) the libidn configure scripts always define HAVE_LIBIDN
> 
> Well, you can build glibc with --enable-add-ons="", thus disabling
> libidn, as the AstLinux people do. I have no idea why one would do that,
> but such systems exist.

indeed, that is the case now.  it wasn't originally that way, but was changed 
long enough ago to cover pretty much all distros now.

defining AI_IDN even when the builder has explicitly disabled libidn support 
does seem kind of weird, but we don't generally export those knobs into the 
headers.  the only cases of generated headers i can think of are gnu/stubs* 
and gnu/lib-names*.  gnu/stubs.h tracks functions, not function features, so
it doesn't seem like a good place for this.

i think the answer today is that we haven't really planned on the ramifications 
here, so supporting detection of it isn't really possible other than at runtime.
most likely it'll remain this way until someone cares enough about it to come up
with a better answer ;).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-help/attachments/20150311/28c77b80/attachment.sig>