[ruby-core:42879] Re: [ruby-trunk - Feature #6065] Allow Bignum marshalling/unmarshalling from C API

2012/2/25 Martin Bosslet <[e-mail]>:
>
> One comment, which is also in reply to why I believe it
> could be dangerous to simply promote rb_big_(un)pack to
> public API: rhey are tightly coupled to our internal
> representation of Bignums. We should probably explicitly
> define the format to be expected of the long array. This
> way we'll separate our internal representation from the
> format that is actually exchanged. This would allow us to
> change the representation internally without breaking
> compatibility in the API layer each time we do so.

I don't think rb_big_pack/rb_big_unpack is tightly coupled to
internal of Bignum.

What the points they expose internal of Bignum?

Note that the format is written in a comment in bignum.c.

  /*
   * buf is an array of long integers.
   * buf is ordered from least significant word to most significant word.
   * buf[0] is the least significant word and
   * buf[num_longs-1] is the most significant word.
   * This means words in buf is little endian.
   * However each word in buf is native endian.
   * (buf[i]&1) is the least significant bit and
   * (buf[i]&(1<<(SIZEOF_LONG*CHAR_BIT-1))) is the most significant bit
   * for each 0 <= i < num_longs.
   * So buf is little endian at whole on a little endian machine.
   * But buf is mixed endian on a big endian machine.
   *
   * The buf represents negative integers as two's complement.
   * So, the most significant bit of the most significant word,
   * (buf[num_longs-1]>>(SIZEOF_LONG*CHAR_BIT-1)),
   * is the sign bit: 1 means negative and 0 means zero or positive.
   *
   * If given size of buf (num_longs) is not enough to represent val,
   * higier words (including a sign bit) are ignored.
   */
  void
  rb_big_pack(VALUE val, unsigned long *buf, long num_longs)

  /* See rb_big_pack comment for endianness and sign of buf. */
  VALUE
  rb_big_unpack(unsigned long *buf, long num_longs)
-- 
Tanaka Akira