[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: providing a libidn compatibility API

From: Nikos Mavrogiannopoulos
Subject: Re: providing a libidn compatibility API
Date: Thu, 26 Jan 2017 14:07:39 +0100

On Thu, Jan 26, 2017 at 1:26 PM, Tim Ruehsen <address@hidden> wrote:
> On Thursday, January 26, 2017 12:58:05 PM CET Nikos Mavrogiannopoulos wrote:
>> Hi,
>>  What do you think of the following merge request:
>> 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).

> 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.

> 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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]