octave-maintainers
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]