a non-error

[r...@amalasoft.com]

Hi All

I noticed some odd behavior in a little app with which I was screwing around and when I went looking for the cause, I found something quite unsettling.

The following code (and a few of its siblings) compiled (though a warning, not nearly stern enough, was generated - a non-compatible equality expression VWEQ).

if rb = single_rb = single_rb then
   form_type := K_form_type_single
 ..

How can this be?  Sure, it came about thanks to some ham-fisted copy-and-paste on my part, but how does a line like that compile?  The subjects of the comparison(s) are EV_RADIO_BUTTONs, btw.

This strikes me as more serious than a warning, as it would likely change program behavior from what was intended.

Thanks

R

[Alexander Kogtenkov]

Indeed, the equality test looks strange. However, it is correct: the equality would give False at run-time. The first part "rb = single_rb" would produce either True or False. Then, this value would be compared with the right-hand side of the second part - "single_rb". This would produce "False" in any case, because neither of the BOOLEAN values are equal to an object of type EV_RADIO_BUTTON.

Is this behavior expcted? Why not report an error if two operands are incompatible? (Compatibility is important here: there could be conversion between a BOOLEAN value and EV_RADIO_BUTTON.) Well, in this particular case it would make sense to report an error (and you noticed a warning). (Side note: in the next version of EiffelStudio it's possible to treat warnings as errors, so such issues would not pass unnoticed.) However, in general case, it's possible that types of operands become compatible. How is it possible?

Suppose, two expressions "a" and "b" have incompatible types A and B respectively. One possibility is that at compile time the type of "a" or the type of "b" is changed in a descendant and these expressions become conforming, effectively making the parent's code absolutely OK. But even without such a redeclaration, the code is fine. Suppose that there is a type C conforming to A and to B at the same time (think about multiple inheritance from the base classes of these types). Then, at run-time the expressions "a" and "b" could evaluate to an object of type C and the equality test would give True. Although the original types were incompatible!

As far as I remember, at some point, the warning VWEQ was treated as an error. But such strict checks ruled out the scenarios described above, doing more harm than good. However, the conditions when VWEQ is reported are on our radar to improve accuracy.

Regards,
Alexander Kogtenkov

r...@amalasoft.com:

[r...@amalasoft.com]

Great explanation.

Thanks 

R

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/1568887477.602693495%40f553.i.mail.ru.

[Eric Bezault]

In fact you should feel lucky to get a warning. In that case:

if some_condition = some_other_condition = some_other_condition then

where `some_condition` and `some_other_condition` are BOOLEANs, there
would be no warning because `some_condition = some_other_condition`
is also a BOOLEAN.

We have a similar gotcha with:

f (a, b: BOOLEAN): BOOLEAN
do
Result := a = b
ensure
Result = a = b
end

where the postcondition should actually be written:

Result = (a = b)

--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com

> r...@amalasoft.com <mailto:r...@amalasoft.com>:

>
> Hi All
>
> I noticed some odd behavior in a little app with which I was
> screwing around and when I went looking for the cause, I found
> something quite unsettling.
>
> The following code (and a few of its siblings) compiled (though
> a warning, not nearly stern enough, was generated - a
> non-compatible equality expression VWEQ).
>
> if rb = single_rb = single_rb then
>    form_type := K_form_type_single
>  ..
>
> How can this be?  Sure, it came about thanks to some ham-fisted
> copy-and-paste on my part, but how does a line like that
> compile?  The subjects of the comparison(s) are
> EV_RADIO_BUTTONs, btw.
>
> This strikes me as more serious than a warning, as it would
> likely change program behavior from what was intended.
>
> Thanks
> R
>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to eiffel-users...@googlegroups.com

> <mailto:eiffel-users...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/eiffel-users/1568887477.602693495%40f553.i.mail.ru

> <https://groups.google.com/d/msgid/eiffel-users/1568887477.602693495%40f553.i.mail.ru?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eiffel-users...@googlegroups.com

> <mailto:eiffel-users...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/eiffel-users/20190919040213.cf48dd763fcaf5d42559c6c92f6fc53b.7a6468c9fb.wbe%40email25.godaddy.com
> <https://groups.google.com/d/msgid/eiffel-users/20190919040213.cf48dd763fcaf5d42559c6c92f6fc53b.7a6468c9fb.wbe%40email25.godaddy.com?utm_medium=email&utm_source=footer>.

[Bertrand Meyer (from phone)]

Alexander’s explanation was masterly!

And (thanks, Eric) there is no tax on parentheses...

Let me add that the underlying issues were discussed at great length in the Ecma committee. The general heuristic s that emerged is that in general it should be permitted (technical term: valid) to ask a question. Hence the general tolerance regarding equality expressions.

— BM

> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/cf9b7642-b12b-b417-1963-61e0f576eafa%40gobosoft.com.