[sr-dev] [PATCH 1/1] websocket: remove libunistring dependency
miconda at gmail.com
Tue Feb 4 21:34:35 CET 2014
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.
On 20/12/13 15:45, Peter Dunkley wrote:
> On 20 December 2013 14:09, Timo Teras <timo.teras at iki.fi
> <mailto:timo.teras at iki.fi>> wrote:
> On Fri, 20 Dec 2013 13:56:08 +0000
> Peter Dunkley <peter.dunkley at crocodile-rcs.com
> <mailto:peter.dunkley at 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
> > flaws and is guaranteed to work in all cases (has this
> > been stubbed out and tested fully by someone here)?
> Did you read the document on the URL it refers to? It is quite
> 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
> > 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
> > 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.
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sr-dev