Hello,
I'm not really a runtime hacker, but I think this sort of function
could be placed in some file (either existing or new) under mono/utils/
directory. Your glib-incomplatible function could not be tested within
eglib tests.
Atsushi Eno
Weeble wrote:
Having diagnosed this bug (when an attribute has a string argument and
the string contains nul, it gets truncated), I've been trying to find
a way to fix it: https://bugzilla.xamarin.com/show_bug.cgi?id=5732
My first attempt just tried to use the available functions in glib,
but it wasn't acceptable because it involved potentially a great many
inefficient reallocs: https://github.com/mono/mono/pull/346
In that pull request, Rodrigo Kumpera recommends that since mono has
its own implementation of glib, it would be better to introduce a new
version of g_utf8_to_utf16 that can handle embedded nuls, which will
probably be useful in other places as well.
Perhaps naively, I have had a go at implementing this. However, when I
tried to add tests for my new function in the eglib test suite, I
realised that the tests are compiled and built against the native glib
as well, so introducing new tests against a new API results in build
failures. You can see what I've tried to do here:
https://github.com/weeble/mono/commit/f545596052125b90ebdd0a302fa3473d768f9d52
I'm willing to keep trying at this if anyone is able to give me some
pointers. Does eglib's API already diverge from glib? If so, are there
any conditional #defines to allow the tests for eglib-specific
functions to run only against eglib and not glib? If not, is it
definitely okay to introduce divergence?
Regards,
Weeble.
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
