[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #42651] Incorrect input validation for strings
From: |
Rik |
Subject: |
[Octave-bug-tracker] [bug #42651] Incorrect input validation for strings |
Date: |
Mon, 30 Jun 2014 20:14:37 +0000 |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 |
Follow-up Comment #2, bug #42651 (project octave):
I think the general behavior of changing transparently between numeric and
char is fine. But I don't think it makes sense in many of these input
validation cases. The change doesn't restrict the range of inputs that the
function can accept, rather it is just restrictive of the options to the
function. This may eliminate an obtuse corner case, but I don't think it
would be overly restrictive.
An example with the first function on the list will probably help.
sort ([66, "A", 67])
ans = ABC
-- Fine
sort ([66, "A", 67], [66 65 67])
ans = BAC
-- No warning, different output, what is it doing?
-- I want a clue that something is amiss.
sort ([66, "A", 67], "ascend")
ans = ABC
-- Fine
mode = double ("ascend")
mode =
97 115 99 101 110 100
sort ([66, "A", 67], mode)
ans = ABC
-- This rather obtuse usage case would be eliminated.
-- But, you could always call sort (..., char (mode))
-- if you felt that you had to do things this way.
In terms of the code base it seems that about 1/2 the instances are already
coded with the is_string predicate and half with the check on error_state. It
would probably be best to decide on a single approach and convert the others
whichever half needs it.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?42651>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/