Re: textToIntevsal(s) and exceptions
Vincent, P1788
On 16 Mar 2015, at 13:34, Vincent Lefevre <vincent@xxxxxxxxxx> wrote:
> On 2015-03-14 01:55:32 -0700, Dmitry Nadezhin wrote:
>> I have a question while testing Marco's reference implementation.
>>
>> There are three exceptions related to textToInterval(s) :
>> InvalidOperand when s doesn't represent Level 2 datum
>
> The standard says: "When an input Level 3 object does not represent a
> Level 2 datum, the result is implementation-defined. An implementation
> shall provide means for the user to specify that an InvalidOperand
> exception be signaled when this occurs."
>
> If the input expects a string, I would say that this can happen when:
> * the input is not a string (e.g. is a language that is not strongly
> typed);
> * the input has the right type "string" but the string is invalid
> as a string (e.g. when UTF-8 encoding is expected but there's an
> invalid UTF-8 sequence).
Those seem good examples.
> But I would say that this mainly depends on the implementation, which
> would have the choice to decide whether a string is valid or not before
> seeing it as a "valid operand" for textToInterval(s). By "valid operand"
> I don't mean that it has a value, just that it is regarded as a valid
> string.
>
>> UndefinedOperation when Level 1 value doesn't exist
>> PossiblyUndefinedOperation when implementation can't determine
>> whether a Level 1 value exists.
>>
>> Which exception shall be signalled in the cases below:
>> a) s is a null pointer;
>
> This is out of scope of the standard: a null pointer is a notion in
> *some* languages. Other languages may handle strings without using
> pointers.
I agree.
> Note that in C, a null pointer is not a string. When an API expects
> a string, a null pointer typically yields undefined behavior.
>
> Here, I would say that the best solution would either be an assertion
> failure (typical solution) or an InvalidOperand exception (see above).
As Vincent implies, "Which exception shall be signalled in this case"
is advice to the implementer, not something the standard should require.
But it does seem reasonable to me that the standard requires "an
implementation shall provide means for the user to specify ..." this
implementation-independent exception. It doesn't ensure that handling
such conditions is portable, but makes portability easier to achieve,
I think.
>> b) s has bad syntax like
>> s="[1,,2]";
>
> This is a valid string (as a string). Thus it is UndefinedOperation
> (except if there's an extension...).
Yes
>> c) s has correct syntax but violates some semantic rule
>> s="[-inf,-inf]";
>> d) s has correct syntax and passes semantic rules, but condition l <= u
>> surely fails
>> s="[2,1]";
>
> I would say that (c) and (d) should be treated in the same way in the
> set-based flavor.
I agree. (b), (c) and (d) should all be treated as UndefinedOperation.
> Anyway neither is regarded as a valid empty set,
> i.e. there is no Level 1 value, except if there's an extension[*] or
> we are in a specific flavor: (d) would be valid in a Kaucher flavor.
Better say "might be valid in a Kaucher flavor". (c) might be OK in a
cset flavor.
> [*] I'm not sure whether this is allowed since the syntax is correct
> but a rule is violated.
>
>> e) s has correct syntax and, but condition l <= u possibly fails
>> s="[1.000000000000000000001,0x1.00000000000001p0]".
>
> Either no exceptions (if the implementation is able to decide that
> l <= u) or PossiblyUndefinedOperation, which has been created for
> this kind of problem.
...
>> The question is not only
>> What does the current text of the standard prescribe ?
>> but also
>> What does a programmer expect ?
>
> The programmer expects that valid strings with no Level 1 value
> are handled correctly, thus giving UndefinedOperation (or possibly
> PossiblyUndefinedOperation in some cases).
>
> The main question is the behavior on invalid strings. IMHO, an
> implementation should give an exception (I would say InvalidOperand,
> which could yield an assertion failure or something like that) when
> this can be detected in an efficient way. In some languages like C,
> it may be impossible to detect (e.g. pointer to an invalid memory
> area, but this typically ends up with a segmentation fault, which
> is another kind of exception, here at the OS level).
This makes sense to me.
However Vincent's comments make me wonder about extensions, see (*) above:
- In 9.4.1 "An implementation may support a more general form of valid interval literals ..."
Should the standard put any restrictions on this?
- Similarly in the set-based flavor, 12.11.5 says
"An implementation may support interval literals of more general syntax ... In this case there shall be a value of the conversion specifier cs of intervalToText in 13.3, that restricts output strings to the portable syntax."
Should the standard put any restrictions on this "more general syntax"?
I prefer not, in either case, but wonder if we are missing something that might bite us later?
John Pryce