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 <[email protected]
<mailto:[email protected]>> wrote:
On Fri, 20 Dec 2013 13:56:08 +0000
Peter Dunkley <[email protected]
<mailto:[email protected]>> 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
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
