J3/04-214 Date: 2004-01-14 To: J3 From: Walt Brainerd Subject: Further Interoperability with C Date: 2003-12-10 at 01:06:23 Request number: Pub-107 Name: Tim Connors E_mail: tconnors+fc20xxreq@astro.swin.edu.au ================================================================= Number: Title: Further Interoperability with C Submitted by: J3 Status: For Consideration References: Basic Functionality: LUNs and file descriptors are currently not interchangable. With the C/Fortran interoperability features, I would *like* to be able to call C/POSIX functions like popen() and be able to operate from a file within fortran. For use of POSIX functions like popen(), I can currently, if I try really hard, come up with completely non-portable solutions to be able to read and write from a pipe to/from a filter (or do other POSIX things like fork/exec etc). I think the ability to use popen() et al. should be codified into the standard. Rationale: Fortran I/O can sometimes be a pain. But doing calculations in Fortran, and passing the results to a C function to do the IO is far worse. I currently create extremely large (multi gig) ASCII files with sparse arrays that can be compressed really well. Ascii files are very portable, and can be transferred between many differnt types of programs. Most of these programs can read gzip compressed files (or can be trivially be made to). But I can't do a normal write (LUN, '(A,4G)') blah where the LUN was previsouly opened by popen to a gzip process encoding to some file on disk. I currently have to encode the file to a temp file, and then run gzip after the fact. You ask why use gzip, when one could either use a proprietry binary format? Part of the reason is outlined above. Part of the reason is that *reading* from the gzip file will be just as fast (or faster) as reading some proprietry format, given that the bottle neck is the disk and network, and not CPU, usually. I can read a gzip file at raw data rates of 30M/S, which when uncompressed is now 300M/S. When turned back into an internal float representation, that could be back near 60M/S. No single disk/network can keep up with that. The 10x disk saving is a feature I find... rather handy. So using external filter programs connected by pipe using popen() is a feature very useful, personally. But codyfying interoperability with POSIX functions in general will be useful for a lot of people. Estimated Impact: Just library functions for UNIX OSs? Force the compiler to keep around the file descriptor when talking to files, so it can use them later? No idea. For inferior OSs, just provide a stub with a warning. Detailed Specification: History: Submitted as Pub-107