[Top][All Lists]

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

Re: LibIDN code quality suggestions

From: Simon Josefsson
Subject: Re: LibIDN code quality suggestions
Date: Wed, 19 Oct 2011 11:18:59 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux)

Bittner Ede <address@hidden> writes:

> Dear Development team,
>       I've tasked at my workplace, to use libidn. I've found some minor
> issues with the library
>       1, the idn-free function (in idn-free.h) misses the EXTERN "C"
> -qualifier, so when I included in the C++, I've get a link error. My
> workaround was to include the file with extern "C", but I think it
> isnt the preferable way, because all other header in the library do
> not need this. I've understand the comaplaints about the idn_free, but
> our production enviroment requires cross platform compatible code, so
> normal free is not an option for us.

Hello Bittner.  Thank you for your attention to detail and your report.

It was a mistake, idn-free.h should also have the extern "C" marker.  I
have fixed this, it will be part of the next release.

>       2, all of the idna_* function return int value, but the idna_strerror
> takes the Idna_rc enum type as it's input parameter, so I've to
> static_cast the return value. This can easily avoided if the function
> returns Idna_rc instead of int. (And it will improve code quality as well)

This will require changing almost all APIs in the library...  I'm a bit
hesitant to do that -- it seems to me as if that would trigger a lot of
warnings in existing Libidn applications that use 'int' for the return
codes and now have to change to use 'Idna_rc' to avoid a similar warning
as you noticed.  Right?

How about if we make idna_strerror (and the other *_strerror functions)
take an int argument instead?  Then at least all library functions are
type-equal when it comes to error codes.


reply via email to

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