Thanks for update. Can you wrap your patch in some define, so it can be applied while keeping the libunistring as alternative? Something like:

#ifdef USE_UTF8_EMBEDDED
 // your code here
#else
 // libunistring function call
#endif

Then it can be pushed without any problem to the master branch, allowing me (and others) to test it easily. After that we can re-evaluate to remove libunistring completely or maybe just make the embedded version default.

Cheers,
Daniel

On 05/02/14 07:45, Timo Teras wrote:
On Tue, 04 Feb 2014 21:34:35 +0100
Daniel-Constantin Mierla <[email protected]> wrote:

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.
I think the patch was not 'blessed' yet.

Peter asked for testing results along the lines of:
Something as simple as a loop through all possible values calling your
function, the libunistring function, and comparing the results would
be perfect.
The calling the function with every possible utf-8 string is
impossible test plan.

Dunno. Perhaps you want to push the patch with dictator hat on, or some
sane test plan can be made. For now, I just applied the patch to my
local builds and forgot this.

- Timo

_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


--
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

Reply via email to