I noticed that e.g. convert_1_to_0() (actually any conversion that goes from wider to narrower) in stralloc.c just chops off the wider part instead of actually leaving out the characters which cannot be represented in the narrower string.
Is there are a reason why it is truncated instead of skipped? I'd presume that actually omitting the characters which cannot be represented would be more correct. Simply truncating them generates garbage.
And, subsequently, if everyone agrees to the above, can/should I fix this?
I noticed that e.g. convert_1_to_0() (actually any conversion that goes from wider to narrower) in stralloc.c just chops off the wider part instead of actually leaving out the characters which cannot be represented in the narrower string.
Is there are a reason why it is truncated instead of skipped? I'd presume that actually omitting the characters which cannot be represented would be more correct. Simply truncating them generates garbage.
convert_1_to_0() et al are only called for strings that don't have any characters that don't fit in the narrower string. ie the thrown away part is always all zeroes. cf find_magnitude*().
And, subsequently, if everyone agrees to the above, can/should I fix this?
There's no need. You could however add a PIKE_DEBUG check that verifies that the thrown away data is zero.
convert_1_to_0() et al are only called for strings that don't have any characters that don't fit in the narrower string. ie the thrown away part is always all zeroes. cf find_magnitude*().
I see. Is there currently a function which does a kind of cast_1_to_0(), i.e. which actually throws out characters which are too wide to be converted?
pike-devel@lists.lysator.liu.se