Melvin Smith <[EMAIL PROTECTED]> writes: > >PIOHANDLE is a low level OS handle (UNIX or Win32) and we to > > create a ParrotIO around it. > >PIOHANDLE is a stdio FILE * and we need to create a ParrotIO around it. > > One more comment. I don't even see the possibility of calling fdopen > from the bytecode level with a FILE *. From the bytecode level, either > we know some OS constants that are typically streams (UNIX 0,1,2) > or the call probably won't come from the bytecode. For the STDIO > case, there is currently no way to even call fdopen() from bytecode > with a valid parameter, it only works for the low level OS handles.
The standard handles are already special cased in the ParrotIO, so 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. > It may not make sense to expose it, but I don't see how we can do without > exposing it for UNIX and low level Win32 without exposing it for STDIO. > > 1 possible solution is: remove PIO_stdio_fdopen altogether and move the code > to PIO_stdio_unit() which actually needs it. Or just set the FDOpen slot in ParrotIOLayerAPI to NULL. The function PIO_stdio_fdopen is static and should not leak out of io_stdio.c bye boe -- Juergen Boemmels [EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
