[erlang-bugs] R16B - io:rows(self()), io:nl(self()) and io:colums(self()) never return .

[Raimo Niskanen]

On Tue, Jun 04, 2013 at 08:09:30PM +0200, PAILLEAU Eric wrote:
> Hi Patrick,
> 
> > The parameter has to be an "IO device" (type device() in the doc)? As
> > the documentation states: "Either standard_io, standard_error, a
> > registered name, or a pid handling IO protocols" (which maybe should
> > read "a pid of a process handling the IO protocol", but anyway :)). The
> > IO protocol is described in stdlib users guide, chapter "The Erlang
> > I/O-protocol".
> > 
> > You basically send a message to a process that never responds, and as
> > IO-servers are not required to respond within a certain time frame, the
> > io-module will wait indefinitely for an answer from the process. This is
> > not a bug.
> 
> I don't totally agree with you, with below arguments :
> 
> - Is there any way to know that a PID is of type io_device ?

No. You can write an IO server yourself, with any bugs you like.
It is up to the writer of the IO server to ensure it is bug free.

> - io:xxxx(<Pid.not.existing>) returns {error,enotsup}
> - io:xxxx(<Pid.not.iodevice>) returns {error,enotsup}
>    (so why self() don't have same error ?)

That must be wrong. io:columns(AnyPid) does not return {error,enotsup}.
io:columns(AnyAtom) returns {error,enotsup} if there is no pid that
registered the name AnyAtom. An atom is not a pid.

io:columns(rex) for instance hangs since the process that registered
'rex' does not implement the IO server protocol.

> - A function should return, even an error or a timeout.

There is no guarantee for that in any programming language.

> - this could be a serious security breach. (<troll>will Erlang ever talk
> about security ?</troll> :>) ...)

io:columns(AnyRandomPid) can have any random effect. If you start
sending random messages to random processes you get random results.

Erlang is built on the assumtion that there are no rouge processes and
incorrect behaviour is a bug to be fixed. Security has to be implemented
towards the outside (not in the node) world.

> 
> So, I don't really care if my patch is graduated or not, but for me
>  this is not a normal behaviour for such functions.
> 
> Regards.
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB