[m-rev.] for review: reading multibyte integers from binary file streams

[Zoltan Somogyi]

On Wed, 9 Jan 2019 02:19:39 +0000 (UTC), Julien Fischer <jfischer at opturion.com> wrote:
> > > +read_binary_int16_be(Result, !IO) :-
> > > +    binary_input_stream(Stream, !IO),
> > > +    read_binary_int16_be(Stream, Result, !IO).
> > > +
> > > +read_binary_int16_be(binary_input_stream(Stream), Result, !IO) :-
> > > +    do_read_binary_uint16_le(Stream, Result0, UInt16LE, IncompleteBytes,
> > > +        Error, !IO),
> > > +    (
> > > +        Result0 = ok,
> > > +        UInt16BE = reverse_bytes(UInt16LE),
> > > +        Int16 = cast_from_uint16(UInt16BE),
> > > +        Result = ok(Int16)
> > 
> > Doing the conversion from byte sequence to an N bit int one way, then
> > reversing the bytes in the N bit int, is slower than building the N bit int
> > the right way in the first place. It does require fewer lines of code.
> > Is that your reason for choosing this approach?
> 
> Yes, specifically it reduces the amount of foreign code required.  Do
> you (or anyone else for that matter) want to avoid the byte reversal?

Yes, I would like to avoid it, *if* it can be done at a reasonable cost
in terms of code size. I showed a way to do it for C, but have no idea
about C# or Java. For example, would an extra endianness parameter
to the foreign_proc procedure, instantiated to different constants
in the _le and _be callers, lead to the tests of the parameter being
compiled away, without warnings or with only warnings that can be shut off?

If there is no way to do that, then the byte reversal approach seems
the best compromise (for all three languages).

Zoltan.