simon-git: spigot (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  9cee402 Rework use of std::enable_if.
  c0b0cc8 StdioStreamReaderRaw: use getc in place of fread.
  3e1e76a iocli: sort out EOF and I/O error handling.

Repository:     https://git.tartarus.org/simon/spigot.git
On the web:     https://git.tartarus.org/?p=simon/spigot.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2018-05-06 21:22:35

commit 9cee402233c41bc6407dac0f39d04a133440411e
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=9cee402233c41bc6407dac0f39d04a133440411e;hp=e39374ec226a4fcae6abd8c246f1858f360c5c29
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun May 6 20:52:27 2018 +0100

    Rework use of std::enable_if.
    
    I saw some C++ in a different code base recently which showed me the
    trick of making enable_if<condition>::type be an unused (and unnamed)
    template parameter, rather than having to uglily use it as the return
    type of your function. This makes the actual function definition look
    more legible.
    
    Also, while I was looking for instances of enable_if to remove, I
    noticed that I'd left some #includes and using directives in a couple
    of files that used it at some point in development but now don't.
    Cleaned those up too.

 baseout.cpp |  3 ---
 error.h     |  6 ------
 spigot.h    | 22 +++++++++++-----------
 3 files changed, 11 insertions(+), 20 deletions(-)

commit c0b0cc8a29bf2d98d21784fe5fb9abded83316d6
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=c0b0cc8a29bf2d98d21784fe5fb9abded83316d6;hp=9cee402233c41bc6407dac0f39d04a133440411e
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun May 6 20:43:32 2018 +0100

    StdioStreamReaderRaw: use getc in place of fread.
    
    The problem with fread is that if you use it on a stream that's
    dribbling data out bit by bit, it will block until the requested
    amount of data has been read. But if spigot has an input source that's
    delivering (say) a single digit at a time at a slow rate, you'd rather
    it produced output digits as soon as it reasonably can, which means
    that as soon as the input delivers it the first digit it should feed
    that immediately into computation in case anything useful can be done
    with it, rather than sitting around waiting for another N-1 digits
    that might not turn up until next week.
    
    This shouldn't be too slow in I/O terms, because of course the
    underlying stdio layer will still be doing larger read operations and
    buffering the result.

 iocli.cpp | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

commit 3e1e76a39e9fda84efcf9840f030cc6d2487a918
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=3e1e76a39e9fda84efcf9840f030cc6d2487a918;hp=c0b0cc8a29bf2d98d21784fe5fb9abded83316d6
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun May 6 21:05:31 2018 +0100

    iocli: sort out EOF and I/O error handling.
    
    The return value from StdioStreamReaderRaw::read_inner() if data was
    not read was EOF (the constant), regardless of whether data couldn't
    be read due to EOF (the condition) or some other I/O error. Also, the
    caller of read_inner in io.cpp never seemed to be checking for EOF
    anyway. I suspect none of this had become obvious because of some side
    effect of the recently-fixed use of fread().
    
    Now read_inner() never returns EOF (which doesn't make much sense in a
    size_t anyway). Instead, it returns 0 for end of file, and on error,
    it simply throws an io_error. A side effect is that it needs to store
    a string describing the input source, to put in the io_error's message.

 iocli.cpp | 37 +++++++++++++++++++------------------
 1 file changed, 19 insertions(+), 18 deletions(-)