Re: udigits_to_I

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...t> [2005-01-26 20:55:44 +0100]:
>
> Look at the functions bitbuff_iu_I and bitbuff_ixu_sub in stream.d, or
> the functions READ-INTEGER and WRITE-INTEGER, to get an idea how to
> convert an integer from/to a byte sequence.

OK.

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

advantages: when stream is GCed, bitbuffer goes without special effort.
disadvantages: lack of modularity (tight coupling with the stream
world), have to save the buffer when allocating bignum in
bitbuff_is_I().  Note that bitbuff_is_I() takes 2 length arguments:
bitsize and bytesize; which is confusing (one should be enough).
bitbuff_ixu_sub() is even worse: it also takes a stream (for error
reporting).

malloc: GC already closes streams, so close() should just free() the
bitbuffer.  no special finalization code.
bitbuff_is_I()&bitbuff_ixu_sub can be rewritten as a general bits<->I
API:

/* 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);

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

/* 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);


-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Ernqvat guvf ivbyngrf QZPN.