mruby-js icon indicating copy to clipboard operation
mruby-js copied to clipboard

Forcing handle_p to have a 32 bit value

Open sadasant opened this issue 9 years ago • 4 comments

When we try mruby-js with mruby compiled with MRB_INT64, using handle_p as a mrb_int pointer values causes a problem with emscripten's API. We think this is because mrb_int is a 64bit int value and emscripten's API expects 32bit pointers.

This solution was found by @scalone

sadasant avatar Feb 12 '16 17:02 sadasant

Personally, I'm reluctant to merge this PR since I prefer to use mrb_int within mruby's environment to play nicer with mruby. I would try to find an alternative way to make sure mrb_int is a 32 bit value via certain build flags. However, feel free to persuade me if you disagree here :)

xxuejie avatar Feb 13 '16 02:02 xxuejie

Hey Xiao!

Well, I'm ok if you don't want to merge this as this seems hackish, but let me see if I can explain the situation. Emscripten API seems to expect 32bit pointer values, if we send 64bit pointer values the API gets overflowed. Defining handle_p as mrb_int is by itself alright, but if we want mrb_int to be of 64 bit values (as we do) it then breaks the emscripten JS-to-C API. The solution is not to set mrb_int to be of 32bit values because we really want mrb_int to have 64 bit values.

I guess in any case I could maintain the fork! Or maybe we can think together on a cleaner solution!

Thanks for your time, if you ever stop near Florida or Brasil please tell me, I can be helpful.

sadasant avatar Feb 13 '16 04:02 sadasant

@sadasant Thanks for the explanation. There're 2 main points I want to raise:

  1. Personally, I would assume wrapping 32 bit pointer values in a 64 bit integer type should be all good, all we need to do is a little careful casting rule. Maybe this is because my C knowledge has become rusty or I might miss something, can we confirm this is the correct behavior?
  2. I'm curious, why do you need 64 bit mrb_int value? Is this due to some other restriction?

xxuejie avatar Feb 13 '16 05:02 xxuejie

Mr. Xuejie! My answers:

  1. I do think all is ok by it self when we wrap 32 bit pointers in 64 bit values, but remember that my problem happens when a javascript function is being called from C with a parameter that is a 64 bit pointer value, the emscripten API gets crazy, it even sends extra parameters than the ones we define. Therefore we concluded that we can't send 64bit int values to js functions from C.
  2. chasonr's mruby fork with bignum support uses 64 bit integers for functions like String.to_i, but we also want our customers to be able to use 64 bit integers in their ruby applications.

2016-02-13 0:39 GMT-05:00 xxuejie [email protected]:

@sadasant https://github.com/sadasant Thanks for the explanation. There're 2 main points I want to raise:

Personally, I would assume wrapping 32 bit pointer values in a 64 bit integer type should be all good, all we need to do is a little careful casting rule. Maybe this is because my C knowledge has become rusty or I might miss something, can we confirm this is the correct behavior? 2.

I'm curious, why do you need 64 bit mrb_int value? Is this due to some other restriction?

— Reply to this email directly or view it on GitHub https://github.com/xxuejie/mruby-js/pull/6#issuecomment-183597782.

Daniel J. Rodríguez S. http://sadasant.com/ http://sadasant.com/

sadasant avatar Feb 13 '16 06:02 sadasant