[#42344] [ruby-trunk - Feature #5964][Open] Make Symbols an Alternate Syntax for Strings — Tom Wardrop <tom@...>

23 messages 2012/02/03

[#42443] [ruby-trunk - Bug #5985][Open] miniruby skews "make benchmark" results — Eric Wong <normalperson@...>

21 messages 2012/02/08

[#42444] [ruby-trunk - Bug #5986][Open] Segmentation Fault — Luis Matta <levmatta@...>

16 messages 2012/02/08

[#42471] [ruby-trunk - Feature #5995][Open] calling io_advise_internal() in read_all() — Masaki Matsushita <glass.saga@...>

20 messages 2012/02/10

[#42560] [ruby-trunk - Bug #6011][Open] ruby-1.9.3-p0/lib/webrick/utils.rb:184: [BUG] Segmentation fault — Vit Ondruch <v.ondruch@...>

12 messages 2012/02/13

[#42579] [ruby-trunk - Bug #6012][Open] Proc#source_location also return the column — Roger Pack <rogerpack2005@...>

14 messages 2012/02/14

[#42685] [ruby-trunk - Bug #6036][Open] Test failures in Fedora Rawhide/17 — Bohuslav Kabrda <bkabrda@...>

14 messages 2012/02/16

[#42697] [ruby-trunk - Bug #6040][Open] Transcoding test failure: Big5 to UTF8 not defined (MinGW) — Luis Lavena <luislavena@...>

10 messages 2012/02/16

[#42813] [ruby-trunk - Feature #6065][Open] Allow Bignum marshalling/unmarshalling from C API — Martin Bosslet <Martin.Bosslet@...>

22 messages 2012/02/23

[#42815] [ruby-trunk - Bug #6066][Open] Fix "control may reach end of non-void function" warnings for clang — Eric Hodel <[email protected]>

15 messages 2012/02/23

[#42857] [ruby-trunk - Feature #6074][Open] Allow alias arguments to have a comma — Thomas Sawyer <transfire@...>

20 messages 2012/02/24

[#42891] [ruby-trunk - Feature #6083][Open] Hide a Bignum definition — Koichi Sasada <redmine@...>

23 messages 2012/02/25

[#42906] [ruby-trunk - Bug #6085][Open] Treatment of Wrong Number of Arguments — Marc-Andre Lafortune <ruby-core@...>

14 messages 2012/02/25

[#42949] [ruby-trunk - Bug #6089][Open] Test suite fails with OpenSSL 1.0.1 — Vit Ondruch <v.ondruch@...>

13 messages 2012/02/26

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

From: Martin Bosslet <Martin.Bosslet@...>
Date: 2012-02-23 11:18:56 UTC
List: ruby-core #42833
Issue #6065 has been updated by Martin Bosslet.


Akira Tanaka wrote:
> 2012/2/23 Tanaka Akira <[email protected]>:
>  
>  > I think your proposal also rely on machine endianness because
>  > it use "long" type.
>  >
>  > I guess bytes in long type (4 bytes or 8 bytes in usual) is
>  > native endian.  Am I wrong?
>  
>  Oops.  [ruby-core:42813] describes "where each of the longs
>  hemselves should probably be in the same order".
>  
>  I think unsigned long should be used only for native endian.
>  unsigned char should be used instead for big- or little- endian data.
>  -- 

Yes, you're right, when using (unsigned) longs we have to pay
attention to byte order within the long itself or go through
the pain of normalizing them to some pre-defined order. 

That's why I'm all for Yui's proposal now. As long as 
sizeof(char) stays one byte, Yui's solution only requires 
specifying the overall byte order once, if I'm not overlooking
something.

I can work around this currently by using for example hex
representations of the numbers for (un-)marshaling, but having
#bindump and #binload would make things a lot easier and more
efficient.

Would it be OK to add #bindump, #binload and rb_big_uminus
to the public API?

----------------------------------------
Feature #6065: Allow Bignum marshalling/unmarshalling from C API
https://bugs.ruby-lang.org/issues/6065

Author: Martin Bosslet
Status: Assigned
Priority: Normal
Assignee: Kenta Murata
Category: core
Target version: 2.0.0


Currently, there's no public C API to create a Bignum. 
There is rb_big_pack and rb_big_unpack that will do the
job, but they are not portable.

Could we offer public functionality that is independent 
of the internal representation for the task of 
marshaling/unmarshalling a Bignum to raw C data types?

I'd like to propose something like

- creating a bignum:

  VALUE rb_big_from_ary(unsigned long *longs, size_t num_longs, int signed)

- retrieving a representation of a Bignum (longs are allocated):

  size_t rb_big_to_ary(VALUE big, unsigned long **longs, int *signed)

For getting a representation, rb_big2str could also be used,
but the above would simplify things when developing an extension
that is in need of Bignum support.

Names and signatures are of course open for discussion,
the example should just serve as an indication of what 
I'm aiming at.

To avoid ambiguity, it would have to be defined how 
the longs are ordered and how the signed flag is to be
interpreted - I would suggest a very simple
representation: Let "longs" be the representation of
the absolute value of the bignum in little- or big-endian
order, where each of the longs themselves should probably
be in the same order, in order to eliminate ambivalence.
Signed is either 0 or 1, so no two's complement or anything
involved. 

I would volunteer to provide a patch for this if we would
agree on something.


-- 
http://bugs.ruby-lang.org/

In This Thread