[erlang-questions] Miller's oversight

ok <>
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:// 
> erlang.org/ml-archive/erlang-questions/200606/msg00206.html>.

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  
worse.
     To prevent forgery, yes, processes/0 should be so marked as well.
(b) add a compiler flag requesting warnings about calls to any of  
those BIFs.
     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 mailing list