[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.
Cheers,
/Simon