At 05:06 PM 11/5/2003 +0100, Juergen Boemmels wrote:
they should not be a reason for fdopen. The main goal why I wanted to
keep fdopen is in cases were parrot is embedded and the bytecode gets
called with an external FILE * pointer. This might be for example
yyin. But is it needed that this must be an opcode or can it be a
method of some layer-object.

fdopen does make sense, especially in the UNIX world as it is common to have a file descriptor that you want to open a standard stream on. It could be a known constant fd, or one passed by some other API, another processes, etc.. More obscure cases include execing() yourself without closing any files, which is possible, but probably not in Parrot since Parrot would just reload bytecode; no need to exec().

But I don't know whether it makes sense as an opcode since it is
platform dependant.

I am glad you are having a go at it, I've been avoiding the issue. :)

-Melvin





Reply via email to