[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cast to char
From: |
mike sander |
Subject: |
cast to char |
Date: |
Mon, 27 Jan 2014 21:24:22 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
I have been working on tests for cast(). i have run into some
inconsistent behaviour with casting to char type. casting any numeric
type to any other numeric type (and logical) seems well behaved. In
cases where the input value is outside the range of the output type, the
output is set to the min/max of the output type as would be expected.
With cast to char, the behavior is different. Here are a couple of
simple examples using direct type conversion:
Case 1: expect char 0 (got undefined). equivalent to cast ( int8(-128),
"char")
>> x=int8(-128)
x = -128
>> z=char(x)
warning: range error for conversion to character value
error: value on right hand side of assignment is undefined
Case 2: expect char 0 (got 0. this one works as expected). Equivalent
to cast(single(-128),"char")
>> x=single(-128)
x = -128
>> z=char(x)
warning: range error for conversion to character value
z =
>> single(z) # use this to output a printable value
ans = 0
>>
Case 3: expect char 255 Equivalent to cast(single(1000),"char")
>> x=single(1000)
x = 1000
>> z=char(x)
warning: range error for conversion to character value
z =
>> single(z) # use this to output a printable value
ans = 0
My initial question is whether cast to char should work as it does for
numeric types? If not, is there information available on how this
should work? If so, I see a couple of changes that should be made:
1) ov-base-int.cc octave_base_int_scalar<T>::convert_to_str_internal()
should compute retval in all cases to eliminate undefined in Case 1.
2) dont return 0 for all out of range inputs. The various
convert_to_str_internal() functions should handle ival < min char value
& ival > max char value as separate cases & return 0/255 in the case of
out of range inputs.
3) none of the numeric conversions report range errors. are these
necessary for char conversion?
With these changes, cast to char would behave similarly to numeric
types. Any guidance is appreciated.
Are any of the above bugs that i should file?
Mike S
- cast to char,
mike sander <=