records

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

records

Thomas Lindgren-3

I get the following very undesirable behaviour for
records.

The program is enclosed as an attachment (my apologies).
Run test:bar/0. Under R7B1 and R8B0, I get the answer
{"aaa", "aaa"}, which means a record of type rec1 is
mistakenly thought to be a record of type rec2.

(Furthermore, since the fields have the same names, but a transposed
order, you also get a nasty return value on top of that.)

Looking at the BEAM code, the basic problem is that
the code doesn't verify that Rec is a record of
the proper type before accessing it. (That is, it doesn't
check that the incoming tuple has the proper arity and
"tag".)

-- Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.erl
Type: application/octet-stream
Size: 552 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20011203/4bec2235/attachment.obj>

Reply | Threaded
Open this post in threaded view
|

Ginger

Johan Bevemyr-2

Sorry, jag ska st?nga av 'auto-reply to all' :-)

/Johan



Reply | Threaded
Open this post in threaded view
|

records

Fredrik Linder-2
In reply to this post by Thomas Lindgren-3
From: "Thomas Lindgren" <thomas.lindgren>

>
> I get the following very undesirable behaviour for
> records.
>
> The program is enclosed as an attachment (my apologies).
> Run test:bar/0. Under R7B1 and R8B0, I get the answer
> {"aaa", "aaa"}, which means a record of type rec1 is
> mistakenly thought to be a record of type rec2.
>
> (Furthermore, since the fields have the same names, but a transposed
> order, you also get a nasty return value on top of that.)
>
> Looking at the BEAM code, the basic problem is that
> the code doesn't verify that Rec is a record of
> the proper type before accessing it. (That is, it doesn't
> check that the incoming tuple has the proper arity and
> "tag".)
>
> -- Thomas
>

The undesirable behaviour that I guess was Thomas' point is the optimization
that record access is not checked (in runtime) to be performed only on
tuples that have the correct first element and the correct tuple size,
generating a runtime error otherwise.

That seems have been forgotten in the following discussion.

/Fredrik

PS. Sorry if this was too obvious DS.