Re: udigits_to_I

[Bruno H. <br...@cl...>]

Sam wrote:
> why is strm_bitbuffer a LISP heap-allocated object and not a malloc'ed
> memory area?

Because it is stored in the stream, as a cache (for speed), and a pointer
to malloc'ed memory becomes invalid after savemem + loadmem. One could
store the malloc'ed memory pointer inside a Fpointer object, but this
would lead to a double indirection instead of a single indirection, plus
the need to check for the foreign pointer's validity before use.

> disadvantages: lack of modularity (tight coupling with the stream
> world)

Yes, this could be improved.

> have to save the buffer when allocating bignum in bitbuff_is_I().

This is normal when we work with Lisp objects.

> bitsize and bytesize; which is confusing (one should be enough)

bytesize = ceiling(bitsize,8);

Indeed just two cheap arithmetic instructions.

> bitbuff_is_I()&bitbuff_ixu_sub can be rewritten as a general bits<->I API:

Good idea. That could go into a new file, to be included from lisparit.d
right after intread.d:
intserial.d  -  serialization of integers as little-endian byte sequences

> /* convert the bit buffer of the given length to a (un)signed integer */
> maygc object bitbuff_to_I (const uintB* buffer, uintL length, bool signed_p);

There probably need to be two variants of this function, one taking an
"const uintB* buffer", the other one taking an "object buffer" (a
simple-array of rank 1 and element-type (unsigned-byte 8)).
I would call these functions LEbytes_to_I and LEbytes_vector_to_I
instead of bitbuff_to_I.

> /* return the minimum size, in bytes, of the buffer where integer will
>    be written */
> uintL I_bitsize (object integer, bool signed_p);

Let's call it I_to_LEbytes_size. It's just a thin wrapper around
I_integer_length.

> /* write the (un)signed integer into buffer of the given length.
>    assumes that length is at least as large as I_bitsize(). */
> void I_to_bitbuff (object integer, uintB* buffer, uintL length, bool signed_p);

Yes. Let's call it I_to_LEbytes.

(I don't like to call it "bitbuffer" because it's only stream.d which goes
down to the bit level. intserial.d goes only down to the uintB level.)

This intserial.d can be written indepedently of any streams. While then
changing stream.d to use it, please be careful with the quality of the
ASSERT_wr_int error message: a stream object with a filename in it is very
useful for the user when an error occurs.

Bruno