Was there any resolution on this topic? I would like to get rid of the unnecessary dependency, the code looked fine at a quick check -- if it is just about utf8 encoding/decoding.

Eventually it can be made a compile time switch with defines for both options, keep the code for both cases and be able to easily switch from one to another.

Cheers,
Daniel

On 20/12/13 15:45, Peter Dunkley wrote:
On 20 December 2013 14:09, Timo Teras <timo.teras@iki.fi> wrote:
On Fri, 20 Dec 2013 13:56:08 +0000
Peter Dunkley <peter.dunkley@crocodile-rcs.com> wrote:

> One of the reasons I used libunistring for this detection is that for
> pretty much all of the code fragments I found online for doing this
> in a "simple" way I saw people pointing out flaws in those
> algorithms.  Can you confirm that this code doesn't have any of those
> flaws and is guaranteed to work in all cases (has this implementation
> been stubbed out and tested fully by someone here)?

Did you read the document on the URL it refers to? It is quite thorough
explanation of what it does, it's correctness and speed. It also
explains that the motivation for implementing it was because all those
snippets in the internet are seriously flawed.

I did see the document.  It looks good.  Does you have first hand experience of whether that code is valid and correct or not?

I personally tend to trust a release library from GNU somewhat more than code on a web-site - however good that web-site and documentation looks.
 
 
> Does this really improve performance?  Only a tiny, tiny, subset of
> libunistring is used.  As a result it doesn't really matter if
> libunistring in general is slow, just whether or not the one function
> used from libunistring is slow.

I'm referring specifically to the function you use. Please check the
URL for performance comparison. While libunistring is not benchmarked
separately, one can see with 0.1 second look at libunistring's
implementation that it will be slower in performance and is likely
something close to iconv()'s implementation.

I don't have any objection to this change as long as you are 100% sure that the algorithm from that web-page works correctly.  The algorithm looks good, the web-page looks good, the documentation looks good, but I'd really prefer it if the implementation was explicitly and fully tested before the libunistring call is replaced.

Something as simple as a loop through all possible values calling your function, the libunistring function, and comparing the results would be perfect.

Regards,

Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda