Bugs in Erlang code -- a common one?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bugs in Erlang code -- a common one?

Kostis Sagonas-3
Some of the bugs in Erlang code that we have discovered using the
new type inference (albeit currently the hard way) are really
subtle and extend beyond simple type clashes.

For example, the code of snmp/src/compile/snmpc.erl at some point
reads:

-----------------------------------------------------------------------
define_cols(...) ->
    SIok = case SubIndex of
               {Parent,[_SI]} when Parent =/= NameOfEntry ->
                   snmpc_lib:print_error(
                     "Invalid parent ~p for table column ~p (should be ~p).",
                     [Parent,NameOfCol,NameOfEntry],Oline),
                   false;
               {NameOfEntry,[SI]} when SI =/= SubIndex ->
                   snmpc_lib:print_error(
                     "Invalid column number ~p for column ~p.",
                     [SI,NameOfCol],Oline),
                   false;
               {NameOfEntry,[SubIndex]} ->
                   ok;
    ....
------------------------------------------------------------------------

and a moment's thought can reveal that there is something fishy here.

By the way, this is the second occurrence of this type of error that
we've found this week in OTP code (there was a similar one in gen_fsm).
I am wondering how frequent is this type of error in Erlang code and
whether this type of error can eventually be detected by the BEAM compiler.

Best,
Kostis.



Reply | Threaded
Open this post in threaded view
|

Bugs in Erlang code -- a common one?

Ulf Wiger-5
Den 2005-03-20 18:49:37 skrev Kostis Sagonas <kostis>:

> For example, the code of snmp/src/compile/snmpc.erl at some point
> reads:
>
> -----------------------------------------------------------------------
> define_cols(...) ->
>     SIok = case SubIndex of
>                {Parent,[_SI]} when Parent =/= NameOfEntry ->
>                    snmpc_lib:print_error(
>                      "Invalid parent ~p for table column ~p (should be  
> ~p).",
>                      [Parent,NameOfCol,NameOfEntry],Oline),
>                    false;
>                {NameOfEntry,[SI]} when SI =/= SubIndex ->
>                    snmpc_lib:print_error(
>                      "Invalid column number ~p for column ~p.",
>                      [SI,NameOfCol],Oline),
>                    false;
>                {NameOfEntry,[SubIndex]} ->
>                    ok;
>     ....
> ------------------------------------------------------------------------
>
> and a moment's thought can reveal that there is something fishy here.

Maybe it's because it's 2:30 am (don't ask), but revealing the
fishiness required more than a moment's thought for
me.  (-:  I will resist the urge to try to investigate what
kind of code the compiler actually puts out.

However...

The clause you left out (in order to save space?)
contained something that at after a moment's thought
was a bit fishy too, but I will not fault Dialyzer for
missing it:

      _Q ->
         snmpc_lib:print_error(
            "Invalid parent for column ~p.",[NameOfCol],Oline)
      end,

In consideration of others who may be reading this list in
the wee hours, I will save you the trouble of chasing the
actual return value of snmpc_lib:print_error/3 -- it's 'ok'.

I spent a few moments trying to figure out if that could
have been deliberate. I decided it probably wasn't.
Such implicit return values are usually to the detriment
of the reader anywy. The ill effect in this case ought to
be one error printout too many.

/Uffe (now going to bed)


Reply | Threaded
Open this post in threaded view
|

Bugs in Erlang code -- a common one?

Luke Gorrie-3
In reply to this post by Kostis Sagonas-3
Kostis Sagonas <kostis> writes:

> Some of the bugs in Erlang code that we have discovered using the
> new type inference (albeit currently the hard way) are really
> subtle and extend beyond simple type clashes.

Interestingly the fishy thing that I see could also not be detected
without false positives in Lisp. Functionalness pays off yet again!




Reply | Threaded
Open this post in threaded view
|

Bugs in Erlang code -- a common one?

Björn Gustavsson-3
In reply to this post by Kostis Sagonas-3
Kostis Sagonas <kostis> writes:
>
> By the way, this is the second occurrence of this type of error that
> we've found this week in OTP code (there was a similar one in gen_fsm).
> I am wondering how frequent is this type of error in Erlang code and
> whether this type of error can eventually be detected by the BEAM compiler.
>

Since it has happened already twice, it seems like a good idea such a
test to the compiler. We'll try to do it for R11B (or possibly for a future
maintenance release of R10B).

/Bj?rn
--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB