Hi,
The current implementation of fdopen op in PIO is buggy. The tests
fail currently on every system except unix. This is because the test
are based on the assumption of 1 being stdout on every system.
Furhtermore the standard handles get autoclosed at exit. This has in
the past lead to problems on Windows.
As we decided long ago to drop support for integer filehandles I
propose the following [1]:
* fdopen should make no assumtions about the nature of the handle,
there are no special values.
* getfd should return the OS-filehandle and not an offset in an
internal array. This makes fdopen and getfd inverse operations:
getfd (fdopen (x)) == x
* The std{in,out,err} can only obtained by getstd{in,out,err}
* fdopen is for communication with external resources. Therefor a
fdopened file should not be closed on destruction. (Unless the user
explicitly requested so)
* a filehandle (PIOHANDLE) is not always an integer, it might also be
a pointer. As its not guaranteed that an INTVAL can hold a pointer,
there needs to be a PMC version of the fdopen op
fdopen (out PMC, in PMC) which takes an UnmangedStruct or PerlInt.
A related point is that currently only one layer can be active. But on
Unix there can be interger FDs and stdio FILE* handles, somewhere in
time there might be also a STRING * layer which operates on memory.
Therefor the external visible open/fdopen functions need to have a
layer argument to create a non-default IO-object. Surely you can
always call PIO_stdio_fdopen(interpreter, pio_stdio_layer, handle)
directly, but it does not feel right.
* Add an layer-argument to PIO_open and PIO_fdopen, which walk the
layerstack and search for the Open-implementation. The current
implentation of PIO_open with the default layer should be
renamed to PIO_open_default.
Comments?
boe
[1] based on discussion with Vladimir Lipskiy
http://groups.google.com/groups?selm=006901c36204%24c181db10%24229d943e%4087w5ovc8gmxcahy
--
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
