[PD-dev] [ pure-data-Bugs-2501709 ] [any2string] converts non-ascii chars to negative values

[SourceForge.net]

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&group_id=55736

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&group_id=55736