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