IDN support in getaddrinfo/getnameinfo

[Corinna Vinschen]

Hi guys,


I'd like to have your opinion.

Yesterday I started a small fun-project. For a while now we have
International Domain Names (IDNs) per RFC 3490.

IDN support usally works like this: There's the libidn project which
provides the "idna_to_ascii" and "idna_to_unicode" functions. And then
there are the getaddinfo and getnameinfo functions. Typically the
getaddinfo and getnameinfo functions don't support IDNs directly, so
IDNs are converted to and from punycode using the libidn functions.

But then there's glibc. Since version 2.3.4, it supports an extension
to the getaddrinfo and getnameinfo functions. Without going into too
much detail, glibc introduced AI_IDN* flags for getaddrinfo and NI_IDN*
flags for getnameinfo which cover the full functionality provided by
the libidn calls. That means, a glibc-aware project does not have to
link against libidn, if it uses the new getaddrinfo/getnameinfo flags.

My small fun-project is adding the AI_IDN* and NI_IDN* flags to Cygwin.
The required libidn functionality exists 100% identically in
kernel32.dll since Windows Vista(1) (IdnToAscii/IdnToUnicode) including
the modifier flags, so it's just a matter of calling the UNICODE
functions GetAddrInfoW/GetNameInfoW and calling these IdnToXXX
functions, just like glibc additionally calls idna_to_ascii_lz, etc. My
new getnameinfo already works with IDNs, the getaddrinfo isn't quite
finished yet.

However, is that really worth the effort? A portable project won't
have a chance but to use libidn functions anyway. If it relies on
AI_IDN/NI_IDN, it will only run on Linux. Well, and on Cygwin in future.
But still, I'm not sure if we should really add this functionality.

What's your stance? Yes or no?


Thanks,
Corinna


(1) There's a downloadable OS extension to support the required calls to
XP and Server 2003 as well, so they are not left out.

[Yaakov (Cygwin/X)]

Post by Corinna Vinschen
My small fun-project is adding the AI_IDN* and NI_IDN* flags to Cygwin.
The required libidn functionality exists 100% identically in
kernel32.dll since Windows Vista(1) (IdnToAscii/IdnToUnicode) including
the modifier flags, so it's just a matter of calling the UNICODE
functions GetAddrInfoW/GetNameInfoW and calling these IdnToXXX
functions, just like glibc additionally calls idna_to_ascii_lz, etc. My
new getnameinfo already works with IDNs, the getaddrinfo isn't quite
finished yet.
However, is that really worth the effort? A portable project won't
have a chance but to use libidn functions anyway. If it relies on
AI_IDN/NI_IDN, it will only run on Linux. Well, and on Cygwin in future.
But still, I'm not sure if we should really add this functionality.
What's your stance? Yes or no?

While the lack of this feature until now hasn't required me to patch
around it, all that means is that any software using this functionality
does so portably (only #ifdef [AN]I_IDN). So while I can't say how many
packages could benefit from this, it's certainly possible that we'll see
more of it going forward. If you're that close, I say go for it.


Yaakov

[Corinna Vinschen]

Post by Yaakov (Cygwin/X)

Post by Corinna Vinschen
My small fun-project is adding the AI_IDN* and NI_IDN* flags to Cygwin.
The required libidn functionality exists 100% identically in
kernel32.dll since Windows Vista(1) (IdnToAscii/IdnToUnicode) including
the modifier flags, so it's just a matter of calling the UNICODE
functions GetAddrInfoW/GetNameInfoW and calling these IdnToXXX
functions, just like glibc additionally calls idna_to_ascii_lz, etc. My
new getnameinfo already works with IDNs, the getaddrinfo isn't quite
finished yet.
However, is that really worth the effort? A portable project won't
have a chance but to use libidn functions anyway. If it relies on
AI_IDN/NI_IDN, it will only run on Linux. Well, and on Cygwin in future.
But still, I'm not sure if we should really add this functionality.
What's your stance? Yes or no?

While the lack of this feature until now hasn't required me to patch
around it, all that means is that any software using this
functionality does so portably (only #ifdef [AN]I_IDN). So while I
can't say how many packages could benefit from this, it's certainly
possible that we'll see more of it going forward. If you're that
close, I say go for it.

Thanks for your encouraging input. I applied my patch.

A neat side-effect of this work is that the net.cc source code got about
18K smaller: I realized that we dropped support for all systems which
didn't come with the getaddrinfo/getnameinfo/freeaddrinfo functions, so
I got rid of the weird autoload code of these functions and the entire
W. Richard Stevens implementation, which I only added as a replacement
for older systems.


Corinna