Bugs item #2501709, was opened at 2009-01-12 17:17 Message generated for change (Comment added) made by mukau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2501709...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: [any2string] converts non-ascii chars to negative values
Initial Comment: belongs to: moocow/pdstring/any2string
non-ascii characters (such as the umlaute 'äöü') are converted to negative values.
instead of i, [any2string] converts to i-256, thus the negative values.
[string2any], OTOH, does seem to work correctly. '246' is converted to 'ö'.
this on pd-vanilla linux with: pdstring version: 0.06 by Bryan Jurish
----------------------------------------------------------------------
Comment By: Bryan Jurish (mukau) Date: 2009-01-17 22:30
Message: fixed in pdstring v0.07 (SVN head).
Can an admin please mark this as "pending"?
----------------------------------------------------------------------
Comment By: Bryan Jurish (mukau) Date: 2009-01-13 21:44
Message:
or even simpler, it could be done with a [mod 256].
... oops, got me!
if you think, that my point is somehow valid
your point is certainly valid: I would prefer to have made [any2string] output unsigned byte values from the beginning, it's really just compatibility issues nagging at me.
what about having a third argument: 0=signed, 1=unsigned ?
also easy, but a bit klunky ... maybe an additional object [any2ustring] for unsigned chars? perhaps we should just check pd-list and see if anyone needs signed chars from [any2string] ...
----------------------------------------------------------------------
Comment By: Roman Haefeli (reduzent) Date: 2009-01-13 20:38
Message: or even simpler, it could be done with a [mod 256].
two reasons, why i want it to have reported and even would prefer it to be changed:
1) it's rather tedious to do it in userspace, since [any2string] outputs lists and for conversion, those need to be serialized, converted and re-packed again. this is not only a complex task to do, it is also very expensive. there is a quick table based 'serialization algorithm, though, but re-packing with only vanilla classes is rather expensive, and exponentially expensive with growing list length in terms of moved atoms [someone please correct me].
2) many classes, that i would find useful to be used together with [any2string] expect 'unsigned chars', that is to say [tcp*], [udp*], [comport] and probably more. as i see it, we have a clash of conventions here and personally i am not able to come up with a good argument for having 'signed chars'.
if you think, that my point is somehow valid, so please lets turn that apparently bogus bug report into a feature request: what about having a third argument: 0=signed, 1=unsigned ?
----------------------------------------------------------------------
Comment By: Bryan Jurish (mukau) Date: 2009-01-13 14:46
Message: This is known behavior, due to the C type used internally ("char", which in C semantics means "signed char").
Non-ASCII characters should be accepted by [string2any] in both "signed char" (ö = -10) and "unsigned char" (ö = 246) format, though.
It would be easy to change [any2string] to output only "unsigned char" values in the range (0..255) rather than "signed char" values in the range (-128..127), but I don't yet see any pressing need to do so, since it would break patches that rely on this behavior (if there are any).
As a workaround, you can use [moses] to detect negative values and [+ 256] to bash them to values in the (0..255) range if you need to.
-Bryan
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2501709...
-
SourceForge.net