On Thursday, January 26, 2017 2:07:39 PM CET Nikos Mavrogiannopoulos wrote: > On Thu, Jan 26, 2017 at 1:26 PM, Tim Ruehsen <tim.rueh...@gmx.de> wrote: > > On Thursday, January 26, 2017 12:58:05 PM CET Nikos Mavrogiannopoulos wrote: > >> Hi, > >> > >> What do you think of the following merge request: > >> https://gitlab.com/jas/libidn2/merge_requests/4 > >> > >> It introduces a (very-limited) compatibility API with libidn, allowing > >> several applications to switch from IDNA2003 to IDNA2008 by changing > >> idna.h with idn2.h. > > > > I just pushed my work on > > > > idn2_to_unicode_8z4z > > idn2_to_unicode_4z4z > > idn2_to_unicode_44i > > idn2_to_unicode_8z8z > > idn2_to_unicode_8zlz > > idn2_to_unicode_lzlz > > > > to branch 'decode' (some commits are to follow)... > > Cool. Is the idn2_* intentional? I was thinking of providing > compatibility in a way that sources do not need to be changed at all > (i.e., provide an idna.h, and compatibility idna_* functions - which > could also be wrappers). It would be very nice if we could compile > programs that use libidn, using libidn2 without any changes (at least > for the majority of them).
The naming is intentional because 1. What about apps providing idna2003 *and* idna2008 (libidn and libidn2) ? 2. idn2_ is the namespace for libidn2 (mainly because of 1) We could use a define being set before #include <idn2.h>, e.g. IDN2_LIBIDN_API. WDYT ? > > If you agree I would (manually) merge your changes into that branch first. > > I certainly do. Note that there few failures in the libidn testsuite, > which I have put them in ifdef XXX. These are in tst_idna2.c, and > tst_idna4.c. The tst_idna4.c failure has to do with ascii_to_8z in > libidn2 allowing multiple dots, while the tst_idn2.c failures are > beyond my knowledge. I'll go through all of these. > > the idna_to_unicode_8z8z() could directly map to idn2_to_unicode_8z8z() - > > the arguments are the same. > > Note that there few small changes from the version you submitted in > gnutls (one which detects non-ascii chars, and another which allows > XN-- as prefix). - Non-ascii detection as a shortcut ? That sounds reasonable. - Allowing XN-- is fine (because of RFC 5890 2.3.1 saying xn-- is case independent). Regards, Tim
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Help-libidn mailing list Help-libidn@gnu.org https://lists.gnu.org/mailman/listinfo/help-libidn
