> Nor should it, EOF is only raised if the proc interface was so poor it
> couldn't signal it in any other way.
That's not very regular, but as long as the documentation clearly states it, I
guess it's OK.
> > NB: I don't know what target Nim aims at (C89? C99? POSIX? the same ones
> > with extensions? some specific platform?), but EOF is not defined as -1 in
> > C99 standard, just as a negative value. So it should be a
> > platform-dependent #define (well, the equivalent for Nim), not a hardcoded
> > value; or if the normal return value is always positive, you can check for
> > negative values.
>
> We target the supported C compilers (Visual, clang, gcc), not the C
> "standard", so I don't care much about "-1 in theory could be something else".
(That's not a matter of compiler but of library (glibc, musl, etc.).)
I cannot spot any obvious mistake in the read* functions any more.
What about the write* functions now? Starting with
proc write(f: File, i: int)
when sizeof(int) == 8:
c_fprintf(f, "%lld", i)
else:
c_fprintf(f, "%ld", i)
this and the following procedures ignore the return values of `fprintf()` and
similar functions, and they don't call `checkErr()` either.
