[m-rev.] for review: io.primitives_{read,write}.m
Julien Fischer
jfischer at opturion.com
Sat Mar 12 14:35:12 AEDT 2022
Hi Zoltan,
On Sat, 12 Mar 2022, Zoltan Somogyi wrote:
> Carve io.primitives_{read,write}.m out of io.m.
>
> library/io.m:
> library/io.primitives_read.m:
> library/io.primitives_write.m:
> As above. The two new private submodules contain the implementations
> (helper predicates) of the operations that respectively read and write
> values of primitive types.
>
> library/MODULES_UNDOC:
> library/library.m:
> List the new submodules as undocumented.
...
> diff --git a/library/io.primitives_read.m b/library/io.primitives_read.m
> index e69de29bb..7e915b97d 100644
> --- a/library/io.primitives_read.m
> +++ b/library/io.primitives_read.m
> @@ -0,0 +1,871 @@
> +%---------------------------------------------------------------------------%
> +% vim: ft=mercury ts=4 sw=4 et
> +%---------------------------------------------------------------------------%
> +% Copyright (C) 1993-2012 The University of Melbourne.
> +% Copyright (C) 2013-2022 The Mercury team.
> +% This file is distributed under the terms specified in COPYING.LIB.
> +%---------------------------------------------------------------------------%
> +%
> +% File: io.primitives_read.m.
> +%
> +% This file handles the details of reading in values of primitive types.
> +%
> +% We communicate results from foreign_procs as separate simple arguments
> +% so the C/Java/etc code does not depend on how Mercury stores its
> +% discriminated union data types. It also avoids memory allocation in
> +% inner loops.
> +%
> +%---------------------------------------------------------------------------%
> +%---------------------------------------------------------------------------%
> +
> +:- module io.primitives_read.
> +:- interface.
> +
> +:- import_module char.
> +
> + % We communicate results from foreign_procs as separate simple arguments
> + % so the C/Java/etc code does not depend on how Mercury stores its
> + % discriminated union data types. It also avoids memory allocation in
> + % inner loops.
That comment just repeats the one in the head of the file.
> +%---------------------------------------------------------------------------%
> +:- implementation.
> +%---------------------------------------------------------------------------%
This code is lacking a C foreign_decl that #includes stdint.h, inttypes.h
mercury_int.h. (Conversely, those headers may not be #included in io.m's
C foreign_decl block.)
...
> +:- pragma foreign_proc("C#",
> + read_char_code_2(File::in, ResultCode::out, Char::out, Error::out,
> + _IO0::di, _IO::uo),
> + [will_not_call_mercury, promise_pure],
> +"
> + io.MR_MercuryFileStruct mf = File;
> + try {
> + int c = io.mercury_getc(mf);
> + if (c == -1) {
> + ResultCode = io.ML_RESULT_CODE_EOF;
> + Char = 0;
> + } else {
> + ResultCode = io.ML_RESULT_CODE_OK;
> + Char = c;
> + }
> + Error = null;
> + } catch (System.Exception e) {
> + ResultCode = io.ML_RESULT_CODE_ERROR;
> + Char = 0;
> + Error = e;
> + }
> +").
As a generaly point, I would fully qualify things in Java and C# foreign_procs.
The required import directives may not be visible when they are inlined via
intermodule-optimization and we cannot also guarantee that user defined names
are not going to clash with partially qualified names in our foreign_procs.
(That last was is fairly unlikely in most cases.)
This is likely an existing issue with this code, but wasn't really a problem
since when they lived in io.m these foreign_procs were never really inlined
across module boundaries anyway.
...
> diff --git a/library/io.primitives_write.m b/library/io.primitives_write.m
> index e69de29bb..bfdc50e0c 100644
> --- a/library/io.primitives_write.m
> +++ b/library/io.primitives_write.m
...
> +:- pred do_write_binary_uint64(stream::in, uint64::in, system_error::out,
> + io::di, io::uo) is det.
> +
> +:- pred do_write_binary_uint64_le(stream::in, uint64::in, system_error::out,
> + io::di, io::uo) is det.
> +
> +:- pred do_write_binary_uint64_be(stream::in, uint64::in, system_error::out,
> + io::di, io::uo) is det.
> +
> +%---------------------------------------------------------------------------%
> +
> +:- implementation.
> +
> +% ZZZ :- import_module array.
> +
> +% ZZZ :- pragma foreign_import_module("C#", array).
Why are those there?
Again, there is a lack of #includes for stdint.h, inttypes.h etc here.
That looks fine otherwise.
Julien.
More information about the reviews
mailing list