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

[Eric Pailleau]

hello Raimo,
ok I give up.
please drop the patch,
and let's stay in this satisfying state.
best regards.


« Envoyé depuis mon mobile » Eric

Raimo Niskanen <raimo+erlang-bugs@REDACTED> a écrit :

>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
>_______________________________________________
>erlang-bugs mailing list
>erlang-bugs@REDACTED
>http://erlang.org/mailman/listinfo/erlang-bugs