[m-rev.] for review: read Mercury files using read_file_as_string

[Zoltan Somogyi]

This diff, which is for review by anyone, gets about a 2% speedup
on my laptop. However, it does raise two issues.

The first is that after this change, the compiler cannot pass the invalid/null_char
test case. As the attached diff shows, instead of reporting null chars in the items
in which they occur, it reports simply that there is a null char in the file, and
does not even attempt to parse it. We could improve on this by reporting e.g.
the line numbers of all the lines that contain NULs, but we could never reproduce
the current expected output of invalid/null_char. The question is, is the speedup
worth this complication in this very rare situation? And if yes, would the above
mentioned improvement be useful to anyone? (It isn't to me.)

The second is that the speedup could be slightly higher if read_file_as_string
returned the max offset in the string it returns, which it has to know in order to
allocate the right amount of memory. While I could write a new variant of
the C version of read_file_as_string that does that, maybe called read_file_as_
string_and_length, I could not do the same for the Java and Erlang versions.
Would anyone like to volunteer?

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.lex_parse_str
Type: application/octet-stream
Size: 1441 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20190726/57e0132d/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.lex_parse_str
Type: application/octet-stream
Size: 124270 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20190726/57e0132d/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NULL_CHAR
Type: application/octet-stream
Size: 1938 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20190726/57e0132d/attachment-0005.obj>