Skip to content

Prohibit MRB_INT64 on 32-bit architecture#4483

Closed
shuujii wants to merge 1 commit into
mruby:masterfrom
shuujii:prohibit-MRB_INT64-on-32-bit-architecture
Closed

Prohibit MRB_INT64 on 32-bit architecture#4483
shuujii wants to merge 1 commit into
mruby:masterfrom
shuujii:prohibit-MRB_INT64-on-32-bit-architecture

Conversation

@shuujii
Copy link
Copy Markdown
Contributor

@shuujii shuujii commented Jun 1, 2019

I think mrb_int size should be less than or equal to pointer size. In the
case of MRB_INT64 on 32-bit architecture, struct RString etc sizes
exceed 6 words at least for now.

I think `mrb_int` size should be less than or equal to pointer size. In the
case of `MRB_INT64` on 32-bit architecture, `struct RString` etc sizes
exceed 6 words at least for now.
@dearblue
Copy link
Copy Markdown
Contributor

dearblue commented Jun 1, 2019

I will oppose.

  • In 32-bit mode kernel space, 32-bit integers are insufficient (in personal terms, I'm glad if I can handle unsigned integer with more than 64 bits...).

    If you define MRB_WITHOUT_FLOAT, the restriction is more strong.

  • gembox "full-core" succeeds even if mrb_int type included in struct RArray or struct RString is replaced with intptr_t (currently mruby-complex and mruby-rational requires modification).

    I do not think that there is a problem because it can not be longer than 32 bits length in 32-bit mode (it would be a bug if there were any).

@shuujii
Copy link
Copy Markdown
Contributor Author

shuujii commented Jun 2, 2019

Thank you for your comment.

Then, as you say, mrb_int size will be allowed to exceed pointer size and type for sizes such as string length it may be better to limit to pointer size (introduce a new type, e.g. mrb_size, which is an alias for intptr_t or uintptr_t?).

Or, it may be possible to limit mrb_int size to pointer size and introduce a type for Fixnum that be allowed to exceed pointer size (e.g. mrb_fixnum).

@dearblue
Copy link
Copy Markdown
Contributor

dearblue commented Jun 2, 2019

There is no objection to the introduction of mrb_size and a change of type.

I think that it is better to leave the definition of mrb_int as it is from the viewpoint of the compatibility so far.


I checked what kind of transition the type of the len field of struct RString has followed:


Other object structures that exceed 6 words in 32-bit mode are struct RBreak defined in include/mruby/error.h.

struct RBreak {
MRB_OBJECT_HEADER;
struct RProc *proc;
mrb_value val;
};

If we define MRB_USE_FLOAT, it will be 6 words length.

  • print object size:

    % cc -m32 -Iinclude -o sizeof sizeof.c && ./sizeof
    size of struct RBreak: 28
    % cc -m32 -Iinclude -DMRB_USE_FLOAT -o sizeof sizeof.c && ./sizeof
    size of struct RBreak: 24
    
  • cat sizeof.c

    #include <mruby.h>
    #include <mruby/error.h>
    #include <stdio.h>
    
    int
    main(int argc, char *argv[])
    {
      printf("size of struct RBreak: %zd\n", sizeof(struct RBreak));
      return 0;
    }

@shuujii
Copy link
Copy Markdown
Contributor Author

shuujii commented Jun 2, 2019

Thank you for your investigation.

I think another fix is necessary for RBreak, so it might be better to create another ticket.

shuujii added a commit to shuujii/mruby that referenced this pull request Aug 23, 2019
…_FLOAT`

ref: mruby#4483 (comment)

In this configuration, `tt` of `RBreak::val` is set into `RBasic::flags`.
shuujii added a commit to shuujii/mruby that referenced this pull request Aug 23, 2019
…_FLOAT`

ref: mruby#4483 (comment)

In this configuration, `tt` of `RBreak::val` is set into `RBreak::flags`.
shuujii added a commit to shuujii/mruby that referenced this pull request Nov 21, 2019
Previously, `mrb_int` was used as the type that represents the buffer size on memory, but the sizes of `RString` and `RArray` exceed 6 words when `MRB_INT64` is enabled on 32-bit CPU.

I don't think it is necessary to be able to represent the buffer size on memory that exceeds the virtual address space. Therefore, for this purpose, introduce `mrb_ssize` which doesn't exceed the sizes of `mrb_int` and pointer.

I think all `mrb_int` used for this purpose should be changed to `mrb_ssize`, but currently only the members of the structures (`RString`,`mrb_shared_string`, `RArray` and `mrb_shared_array`) are changed.
shuujii added a commit to shuujii/mruby that referenced this pull request Nov 21, 2019
Previously, `mrb_int` was used as the type that represents the buffer size
on memory, but the sizes of `RString` and `RArray` exceed 6 words when
`MRB_INT64` is enabled on 32-bit CPU.

I don't think it is necessary to be able to represent the buffer size on
memory that exceeds the virtual address space. Therefore, for this purpose,
introduce `mrb_ssize` which doesn't exceed the sizes of `mrb_int` and
pointer.

I think all `mrb_int` used for this purpose should be changed to
`mrb_ssize`, but currently only the members of the structures (`RString`,
`mrb_shared_string`, `RArray` and `mrb_shared_array`) are changed.
matz added a commit that referenced this pull request Nov 22, 2019
…ffer-size-on-memory

Introduce `mrb_ssize` type for buffer size on memory; ref #4483
@shuujii
Copy link
Copy Markdown
Contributor Author

shuujii commented Nov 24, 2019

I close this PR because it has been resolved via #4662 and #4835.

@shuujii shuujii closed this Nov 24, 2019
@shuujii shuujii deleted the prohibit-MRB_INT64-on-32-bit-architecture branch November 24, 2019 01:33
shuujii referenced this pull request Nov 17, 2020
- Remove `mrb_ssize`
- Fix `MRB_FIXNUM_{MIN,MAX}` to 32 bits on `MRB_NAN_BOXING`
matz added a commit that referenced this pull request Nov 17, 2020
I misunderstand the meaning of #4483. Sorry.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants