[erlang-questions] Miller's oversight
Mon Mar 26 03:38:41 CEST 2007
On 26 Mar 2007, at 12:35 pm, Mark S. Miller wrote:
> That's the good news. The bad news is that Erlang processIds are
> forgeable, making the above technique irrelevant. See <http://
This is sadly true. However, I think it is useful to distinguish
between Erlang the language
and the full Erlang/OTP system. If you took the language described
in the old Erlang book and
just removed list_to_pid/1 you would have something that was
recognisably Erlang and in which
process IDs were NOT forgeable. Virtually all Erlang techniques
would survive unchanged, and
the vast majority of Erlang code would be unaffected.
As a start towards this,
(a) extend the list of BIFs flagged as "Warning: this BIF is intended
for debugging only".
process_info/1 is so marked but process_info/2 is not; surely
*normal* Erlang processes
have no business looking inside others. process_flag/3 is even
To prevent forgery, yes, processes/0 should be so marked as well.
(b) add a compiler flag requesting warnings about calls to any of
Better still, make that the default, and require a special flag
NOT to warn.
It isn't enough to just use Erlang's existing cross-reference
facilities; the normal
Erlang programmer shouldn't even remember the names of these
BIFs so would find it
hard to check for them.
(c) Long term, create a new 'unsafe' module and move all such unsafe
BIFs to it.
(Burroughs did something very like this in their NEWP language.)
Providing reflection facilities in a language for the sake of
debugging (or for any other
reason) usually seems to result in a language whose encapsulation is
more apparent than
real. It is for this reason that in Quintus Prolog it is possible
(if you work at it) to
call any predicate in any module. It is for this reason that
Smalltalk, whose encapsulation
of instance variables appears to be total does in fact let any object
change any instance
variable in any other object (using #instanceVariableAt:put:).
More information about the erlang-questions