Add IO->FILE* for interfacing with C functions

[timholy]

In particular, I've found fdopen useful when interfacing with C libraries that do I/O. For example, suppose you need to parse the magic bytes of the file to check that it's of the type you expect (which you might do in Julia), then hand off I/O to a C function.

Rather than implementing this functionality multiple times in different packages, it seemed like it might be time to consider standardizing such functionality. Alternatively, we could have a CIO.jl package.

This has only been tested on Linux, although I tried to write it in a way that should work on all platforms.

It might be prettiest to make ccall automatically convert an IOStream to a FILE*, if possible. However, there might be performance issues arising from the fseek, so it might be better not to make this too easy.

Finally, the main reason this is a WIP: if the stream is opened in mode "w", fdopen segfaults. HOWEVER, that seems to be because of this odd behavior:

julia> s = open("/tmp/test.dat", "w")
IOStream(<file /tmp/test.dat>)

julia> isreadable(s)
true

That seems like a bug to me. If you work around it with

julia> FILEp = fdopen(fd(s), "w")
Ptr{Void} @0x00000000048a3950

then there is no segfault.

[StefanKarpinski]

I'm not thrilled with the idea of adding three exports for this, but yes, we obviously need to be able to do this.

[timholy]

I hear you. I suppose one option would be to keep this as an unexported interface. ccalls are kindof black-diamond territory, anyway.

[ihnorton]

👍 was just looking for a way to do this for libpng.

[timholy]

Can you guess what prompted this? :-)

[StefanKarpinski]

How about having a CFileHandle type and providing a conversion from an open IO object to that. Then you can override seek and tell methods for that type.

[timholy]

That's prettier. It will still be 2 exports, you're OK with that?

[StefanKarpinski]

That's only one export: CFileHandle. What's the other one?

[timholy]

Duh. Of course you're right.

[StefanKarpinski]

Calling it CFILE or C_FILE might be better.

[timholy]

It's a pointer to a FILE struct, not a FILE struct. CptrFILE? CFILEptr?

But I like the idea of having FILE in the name, it makes it greppable.

[timholy]

OK, I went with CFILE. The OS is allocating one, so it's not as misleading as I initially suggested.

Once #5058 is deemed suitable, this should be safe and ready to merge.