comp.lang.ada
 help / color / mirror / Atom feed
* Test for > 'last
@ 2003-03-14 12:06 Peter Richtmyer
  2003-03-14 12:24 ` Jeffrey Creem
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Peter Richtmyer @ 2003-03-14 12:06 UTC (permalink / raw)


This may be trivial, but I have come across some code
in a (weapon control) system that does checks similar
to:

    ---------------------------------------
    if enum_input < enum_type'first or 
       enum_input > enum_type'last then 
       -- handle the input error
    ---------------------------------------

I have experimented, and found that this type of code
could do at least 3 different things, depending upon 
the compiler and error-checking options:

 - always say that "enum_input" is OK, regardless of its "validity"
 - always raise an exception when the data is invalid
 - work as intended

I think they were running the code with no exceptions
being raised.

I also think the code should be using the 'valid test instead.

But I am wondering whether people think the original code
is OK, sort of wrong, really grossly wrong, or what.

thanks,
Peter



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Test for > 'last
  2003-03-14 12:06 Test for > 'last Peter Richtmyer
@ 2003-03-14 12:24 ` Jeffrey Creem
  2003-03-14 17:22 ` Ant
  2003-03-15  2:02 ` Jeffrey Carter
  2 siblings, 0 replies; 6+ messages in thread
From: Jeffrey Creem @ 2003-03-14 12:24 UTC (permalink / raw)


Someplace between mostly wrong and grossly wrong but likely to be just
optimized away.
(Unless enum_input is a variable of a base type that enum_type is a subtype
of in which case this could
be valid...but I doubt it).

In any case, in Ada 83, there was no 'valid so people were often temped to
write stuff like this..Note that
if data got into enum_input via something like text_io.enumeration_io then
this is incorrect but totally harmless code.

If it got there via some unchecked_conversion or similar approach and there
are not already other reasons
why the data must be valid, then this is not sufficient to detect bad input.


Note that just because it is technically wrong does not mean that if this
code were run with checks suppressed that it would not accomplish what was
desired....It is just that if it did accomplish what was desired, it is only
due to relying on behaviour that is not required by the LRM.




13.9.1 Data Validity

                Bounded (Run-Time) Errors

If the representation of a scalar object does not represent a value of the
object's subtype (perhaps because the object was not initialized), the
object is said to have an invalid representation. It is a bounded error to
evaluate the value of such an object. If the error is detected, either
Constraint_Error or Program_Error is raised. Otherwise, execution continues
using the invalid representation. The rules of the language outside this
subclause assume that all objects have valid representations. The semantics
of operations on invalid representations are as follows:

If the representation of the object represents a value of the object's type,
the value of the type is used.

If the representation of the object does not represent a value of the
object's type, the semantics of operations on such representations is
implementation-defined, but does not by itself lead to erroneous or
unpredictable execution, or to other objects becoming abnormal.

"Peter Richtmyer" <prichtmyer@yahoo.com> wrote in message
news:1b585154.0303140406.124c3312@posting.google.com...
> This may be trivial, but I have come across some code
> in a (weapon control) system that does checks similar
> to:
>
>     ---------------------------------------
>     if enum_input < enum_type'first or
>        enum_input > enum_type'last then
>        -- handle the input error
>     ---------------------------------------
>





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Test for > 'last
  2003-03-14 12:06 Test for > 'last Peter Richtmyer
  2003-03-14 12:24 ` Jeffrey Creem
@ 2003-03-14 17:22 ` Ant
  2003-03-14 18:10   ` Vinzent Hoefler
  2003-03-15  2:02 ` Jeffrey Carter
  2 siblings, 1 reply; 6+ messages in thread
From: Ant @ 2003-03-14 17:22 UTC (permalink / raw)


"Peter Richtmyer" <prichtmyer@yahoo.com> wrote in message
news:1b585154.0303140406.124c3312@posting.google.com...
> This may be trivial, but I have come across some code
> in a (weapon control) system that does checks similar
> to:
>
>     ---------------------------------------
>     if enum_input < enum_type'first or
>        enum_input > enum_type'last then
>        -- handle the input error
>     ---------------------------------------

[...]

> But I am wondering whether people think the original code
> is OK, sort of wrong, really grossly wrong, or what.

I would rather do this:

if enum_input not in enum_type'first .. enum_type'last then
  -- handle error
end if;





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Test for > 'last
  2003-03-14 17:22 ` Ant
@ 2003-03-14 18:10   ` Vinzent Hoefler
  2003-03-17 11:28     ` Ant
  0 siblings, 1 reply; 6+ messages in thread
From: Vinzent Hoefler @ 2003-03-14 18:10 UTC (permalink / raw)


"Ant" <ant@work.invalid> wrote:

>"Peter Richtmyer" <prichtmyer@yahoo.com> wrote in message
>news:1b585154.0303140406.124c3312@posting.google.com...
>> This may be trivial, but I have come across some code
>> in a (weapon control) system that does checks similar
>> to:
>>
>>     ---------------------------------------
>>     if enum_input < enum_type'first or
>>        enum_input > enum_type'last then
>>        -- handle the input error
>>     ---------------------------------------
>
>[...]
>
>> But I am wondering whether people think the original code
>> is OK, sort of wrong, really grossly wrong, or what.
>
>I would rather do this:
>
>if enum_input not in enum_type'first .. enum_type'last then
>  -- handle error
>end if;

And would be wrong, too, if enum_input also has the type enum_type.

If you look closer to this, this statement does not make sense and the
compiler is indeed not required to check this, because the contract
tells him, this condition will *always* be false (even if in fact it
might not be). What else should a enum_input contain than some value
of enum_type?

Either use 'Valid or use a type that is allowed to contain values
outside the range of the type to be compared with.


Vinzent.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Test for > 'last
  2003-03-14 12:06 Test for > 'last Peter Richtmyer
  2003-03-14 12:24 ` Jeffrey Creem
  2003-03-14 17:22 ` Ant
@ 2003-03-15  2:02 ` Jeffrey Carter
  2 siblings, 0 replies; 6+ messages in thread
From: Jeffrey Carter @ 2003-03-15  2:02 UTC (permalink / raw)


Peter Richtmyer wrote:
> 
>     ---------------------------------------
>     if enum_input < enum_type'first or 
>        enum_input > enum_type'last then 
>        -- handle the input error
>     ---------------------------------------

Without knowing the type of Enum_Input, it's impossible to tell. This is 
simply an awkward way to say

if Enum_Input not in Enum_Type then

So it appears the coder did not have a lot of Ada experience and 
probably didn't understand what he was doing.

If Enum_Input is of type Enum_Type, then the compiler probably optimized 
the condition to False and reduced the statement to the else part; if 
there's no else part, then it would optimize the entire if away.

-- 
Jeff Carter
"That was the most fun I've ever had without laughing."
Annie Hall




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Test for > 'last
  2003-03-14 18:10   ` Vinzent Hoefler
@ 2003-03-17 11:28     ` Ant
  0 siblings, 0 replies; 6+ messages in thread
From: Ant @ 2003-03-17 11:28 UTC (permalink / raw)


"Vinzent Hoefler" <JeLlyFish.software@gmx.net> wrote in message
news:b4t635$22plon$1@ID-175126.news.dfncis.de...
>"Ant" <ant@work.invalid> wrote:

[...]
>>I would rather do this:
>>
>>if enum_input not in enum_type'first .. enum_type'last then
>>  -- handle error
>>end if;
>
>And would be wrong, too, if enum_input also has the type enum_type.
>
>If you look closer to this, this statement does not make sense and the
>compiler is indeed not required to check this, because the contract
>tells him, this condition will *always* be false (even if in fact it
>might not be). What else should a enum_input contain than some value
>of enum_type?
>
>Either use 'Valid or use a type that is allowed to contain values
>outside the range of the type to be compared with.

Yes. I can see it's all nonesense now, in the context of enumerated
types. I was looking at the test, and stating my preference for the use
of 'x in y .. z', rather than 'x < y or x > z ' type of construct.





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-03-17 11:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-14 12:06 Test for > 'last Peter Richtmyer
2003-03-14 12:24 ` Jeffrey Creem
2003-03-14 17:22 ` Ant
2003-03-14 18:10   ` Vinzent Hoefler
2003-03-17 11:28     ` Ant
2003-03-15  2:02 ` Jeffrey Carter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox