Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Change of behavior of demarshalling an empty file #7142
Original bug ID: 7142
The program in Section "Steps to Reproduce" used to work in ocaml 4.01 and fails with the exception "input_value: truncated object" on the current trunk.
Before that commit, the function caml_input_val was raising the EOF exception while trying to read the magic number starting marshaled representation, and now the function call below fails with "input_value: truncated object" (is the object really truncated if there is no object ?):
I don't know if this is a bug or if the original behavior was an abuse the demarshaling function. In the later case, it should be documented.
Steps to reproduce
let write oc n =
let read ic =
let () = begin
Comment author: @zoggy
When reading from a pipe or a network communication, with the new implementation there is no way to distinguish between a closed channel (end of communication) from a bad transmitted value.
This change of behaviour has already broken Stog. Ok, I should have tested it before the release, but since 4.03.0 broke a lot of libraries Stog depends on (and not only mine), this was not possible in a reasonable amount of time.
Comment author: berenger
This bug also hits clangml.
Comment author: @alainfrisch
This is an interesting argument in favor of restoring the previous behavior.
Damien: would you agree to that?
Comment author: @xavierleroy
I am probably the one to blame for this change of behavior, although it was not on purpose!
The old implementation of the unmarshaler would raise End_of_file if it hit end-of-file while reading the first 20 bytes of data (the header), and Failure "input_value: truncated object" if it hit end-of-file while reading the remainder of the marshaled data.
The 4.03 implementation raise Failure "input_value: truncated object" in both cases.
An arguably sensible behavior would be to raise End_of_file if the input is already at end-of-file, and Failure "input_value: truncated object" if end-of-file is hit later.
Comment author: gabelevi
All of my use cases are for two processes communicating with each other via Unix.select followed by input_value. The End_of_file exceptions that we expect should not come in the middle of reading an object, so xleroy's suggestion would work for us.