Fix the behaviour of FileGroup when seeking too far.

Previously, if you did a seek off the end of the file group,
the seek would return an error.

This is not what fseek() does; it returns no error, and preserves
the file pointer (returned by ftell()) as if the seek had been
successful.  fread()s after a too-far seek return no data, of
course.

Parsing some files (the example used to find the bug was a
H264 MP4) involves a seek which is to the byte after the end
of the mp4 file.  If this fails the whole header parsing fails
and DCP-o-matic refuses to use the file.

1 files changed, 9 insertions, 2 deletions

diff --git a/test/file_group_test.cc b/test/file_group_test.cc
index cfcaacfc2..05127828c 100644
--- a/test/file_group_test.cc
+++ b/test/file_group_test.cc
@@ -92,8 +92,15 @@ BOOST_AUTO_TEST_CASE (file_group_test)
 	BOOST_CHECK_EQUAL (fg.read (test, total_length * 3), total_length - pos);
 	BOOST_CHECK_EQUAL (memcmp (data + pos, test, total_length - pos), 0);
 
-	/* Bad seek */
-	BOOST_CHECK_EQUAL (fg.seek (total_length * 2, SEEK_SET), -1);
+	/* Seeking off the end of the file should not give an error */
+	BOOST_CHECK_EQUAL (fg.seek (total_length * 2, SEEK_SET), total_length * 2);
+	/* and attempting to read should return nothing */
+	BOOST_CHECK_EQUAL (fg.read (test, 64), 0);
+	/* but the requested seek should be remembered, so if we now go back (relatively) */
+	BOOST_CHECK_EQUAL (fg.seek (-total_length * 2, SEEK_CUR), 0);
+	/* we should be at the start again */
+	BOOST_CHECK_EQUAL (fg.read (test, 64), 64);
+	BOOST_CHECK_EQUAL (memcmp (data, test, 64), 0);
 
 	/* SEEK_SET */
 	BOOST_CHECK_EQUAL (fg.seek (999, SEEK_SET), 999);