Why is there an output_string but not a read_string function?


#1

In the Pervasives module, we have an output_string which takes care of writing a string on an output channel, even if the string is huge.

On the other hand, there is no read_string:in_channel -> string function that reads all the remaining text in an input channel (assuming it corresponds to a text file).

Is this deliberate ? I would naively have thought that reading and writing are rather symmetrical operations.


#2

What is string? The entire file? What if it’s too big/has no EOF?


#3

It shouldn’t be hard to raise exceptions in those cases, should it ? It’s not very difficult to write a small function that does that, but I’m surprised that it’s not builtin.


#4

I’m glad you asked, someone motivated could definitely
try and revive https://github.com/ocaml/ocaml/pull/640 which adds some
helpers to the stdlib’s IO. Good luck!


#5

I’m glad other people share my concerns too :slight_smile:


#6

Indeed, this is quite useful when doing system programming.
Several libraries define such a function.
It is named string_of_file usually.
For example:

opam install ocaml-compiler-libs

Then use Misc.string_of_file.


#7

It is not too hard, because it is impossible to do “correctly”. The read operation on a file might block forever, e.g. a file on an NFS mount on a connection that went away.


#8

I must point out that “compiler libs” (the set of modules that are part of the compiler implementation) give currently no guarantee about the stability of their API. You should only use it if you really need it and you know what you are doing.
So for a simple function such as string_of_file that can be implemented independently from the compiler codebase, you really should use any other library (containers, bos, base) instead of compiler libs.


#9

Or we could try to get @c-cube PR merged in the stdlib.


#10

Sure, that would be nice as well.


#11

Serious question: is anyone motivated to take the PR over? (not sure how easy it can be).