Discussion:
encodings, bugs 2183219/2183437
Mark Ellis
2008-12-23 17:14:26 UTC
Permalink
Hi Guys

Putting this out to a wider audience because I haven't dealt with this
much before. David's sharing the pain in the bug, but I thought why
should you lot miss out :)

The two bugs referenced in the title relate to segfaults caused by
non-ascii characters being passed to wstr_to_ascii, resulting in an
unchecked NULL return.

The immediate response, wstr_*_ascii is evil :)

However, the solution isn't as obvious, at least to me. I see two
options.

1) change all wstr_* to utf8, and assume the system can deal with utf8.
Advantages, it's quite easy. Disadvantages, it's a big assumption and
will blow up.

2) use utf8 internally, so we never lose anything in conversions from
either the host or the device. We then have to convert to the locale
when going out to the host. Much more work, but more reliable.


Ok, so 2) sounds good. When getting input from the host we convert from
locale to utf8 and lose nothing. However, what I can't see is what to do
if, for instance, we get a wstr from the device, then convert that to
the locale that can't deal with the characters in the wstr ? Substitute
something like "__untranslatable__" ?

Mark
David Eriksson
2008-12-23 19:34:01 UTC
Permalink
Post by Mark Ellis
Hi Guys
Putting this out to a wider audience because I haven't dealt with this
much before. David's sharing the pain in the bug, but I thought why
should you lot miss out :)
The two bugs referenced in the title relate to segfaults caused by
non-ascii characters being passed to wstr_to_ascii, resulting in an
unchecked NULL return.
The immediate response, wstr_*_ascii is evil :)
However, the solution isn't as obvious, at least to me. I see two
options.
1) change all wstr_* to utf8, and assume the system can deal with utf8.
Advantages, it's quite easy. Disadvantages, it's a big assumption and
will blow up.
2) use utf8 internally, so we never lose anything in conversions from
either the host or the device. We then have to convert to the locale
when going out to the host. Much more work, but more reliable.
Ok, so 2) sounds good. When getting input from the host we convert from
locale to utf8 and lose nothing. However, what I can't see is what to do
if, for instance, we get a wstr from the device, then convert that to
the locale that can't deal with the characters in the wstr ? Substitute
something like "__untranslatable__" ?
Maybe another possible way out out would be to check the iconv(3) return
code and if it is EILSEQ, patch *inbuf to contain for example '?', and
keep going...

Merry Christmas!

David, http://www.divideandconquer.se/
Mark Ellis
2008-12-23 23:18:26 UTC
Permalink
Post by David Eriksson
Post by Mark Ellis
Hi Guys
Putting this out to a wider audience because I haven't dealt with this
much before. David's sharing the pain in the bug, but I thought why
should you lot miss out :)
The two bugs referenced in the title relate to segfaults caused by
non-ascii characters being passed to wstr_to_ascii, resulting in an
unchecked NULL return.
The immediate response, wstr_*_ascii is evil :)
However, the solution isn't as obvious, at least to me. I see two
options.
1) change all wstr_* to utf8, and assume the system can deal with utf8.
Advantages, it's quite easy. Disadvantages, it's a big assumption and
will blow up.
2) use utf8 internally, so we never lose anything in conversions from
either the host or the device. We then have to convert to the locale
when going out to the host. Much more work, but more reliable.
Ok, so 2) sounds good. When getting input from the host we convert from
locale to utf8 and lose nothing. However, what I can't see is what to do
if, for instance, we get a wstr from the device, then convert that to
the locale that can't deal with the characters in the wstr ? Substitute
something like "__untranslatable__" ?
Maybe another possible way out out would be to check the iconv(3) return
code and if it is EILSEQ, patch *inbuf to contain for example '?', and
keep going...
Now _that_is an idea I like, might take me a while to figure out but
definitely doable, nice one !
Post by David Eriksson
Merry Christmas!
Damn, does that mean I need to stop coding :)

Merry Christmas !

Mark
gruna
2008-12-24 15:53:37 UTC
Permalink
Hi All,

i do not manage to install synce-opensync-plugin-2x.py
It is placed unter /usr/lib/opensync/python-plugins

I've checked many forums, but do not find the solution.
msynctool --listplugins does not show synce plugin

Regards,
Gruna
Mark Ellis
2008-12-24 16:14:32 UTC
Permalink
Post by gruna
Hi All,
i do not manage to install synce-opensync-plugin-2x.py
It is placed unter /usr/lib/opensync/python-plugins
I've checked many forums, but do not find the solution.
msynctool --listplugins does not show synce plugin
Regards,
Gruna
Have you installed the opensync python plugin ?

Mark
gruna
2008-12-24 16:40:27 UTC
Permalink
Yes,

Just reinstalled it one more time, but without result.

Regards,
Gruna
Post by Mark Ellis
Post by gruna
Hi All,
i do not manage to install synce-opensync-plugin-2x.py
It is placed unter /usr/lib/opensync/python-plugins
I've checked many forums, but do not find the solution.
msynctool --listplugins does not show synce plugin
Regards,
Gruna
Have you installed the opensync python plugin ?
Mark
------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
SynCE-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/synce-devel
Continue reading on narkive:
Loading...