4 Feb
2014
4 Feb
'14
10:34 p.m.
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(a)iki.fi
<mailto:timo.teras@iki.fi>> wrote:
On Fri, 20 Dec 2013 13:56:08 +0000
Peter Dunkley <peter.dunkley(a)crocodile-rcs.com
<mailto:peter.dunkley@crocodile-rcs.com>> wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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