Project

General

Profile

Actions

Feature #8568

closed

Introduce RbConfig value for native word size, to avoid Fixnum#size use

Added by headius (Charles Nutter) almost 11 years ago. Updated over 2 years ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:55638]

Description

Fixnum#size is not really useful to represent native word size across all platforms and implementations. On JRuby, for example, our Fixnum is always represented as a 64-bit Java "long" value, regardless of the underlying native platform. There may be other implementations that fix Fixnum's size to a specific bit width as well. Therefore, using Fixnum#size to determine the size of a word on the underlying native platform is not reliable.

I propose two additions to Ruby:

  1. RbConfig value "word_size" for native word size. This could reflect bit size (32, 64) or byte size (4, 8).

  2. A constant, somewhere in Ruby, to provide access to this value more directly. I'm not sure where this should go. ObjectSpace::WORD_SIZE?


Files

sizeof.diff (2.11 KB) sizeof.diff nobu (Nobuyoshi Nakada), 07/03/2013 04:56 PM

Related issues 1 (0 open1 closed)

Related to Ruby master - Feature #8553: Bignum#size (and Fixnum#size)Closed06/21/201308/31/2013Actions

Updated by nobu (Nobuyoshi Nakada) almost 11 years ago

In current CRuby, Fixnum is always limited as long, so Fixnum#size represents sizeof(long), not word size.
But it depends on what you define "word" as, of course.
If you mean SIZEOF_VALUE by "word size", it's simply a bug to use Fixnum#size for that purpose.

A way to achieve size of a pointer is [""].pack("p").size currently.

Updated by headius (Charles Nutter) almost 11 years ago

Size of a pointer is probably what I'm looking for, since that's usually what people will be using it for. However, implementations that can't give out real pointers can't support pack("p"), so that's not a portable option either.

So... RbConfig::CONFIG['pointer_size'] and some constant?

Updated by nobu (Nobuyoshi Nakada) almost 11 years ago

'pointer' or 'value'?

I'm curious for what purpose people use that size.
Pointers are not used usually in ruby, I think.

Updated by naruse (Yui NARUSE) almost 11 years ago

The place where word size info should be seems RbConfig, if it is needed.

nobu (Nobuyoshi Nakada) wrote:

'pointer' or 'value'?

I'm curious for what purpose people use that size.
Pointers are not used usually in ruby, I think.

See #8553

Updated by akr (Akira Tanaka) almost 11 years ago

2013/6/25 headius (Charles Nutter) :

Issue #8568 has been reported by headius (Charles Nutter).

I propose two additions to Ruby:

  1. RbConfig value "word_size" for native word size. This could reflect bit size (32, 64) or byte size (4, 8).

  2. A constant, somewhere in Ruby, to provide access to this value more directly. I'm not sure where this should go. ObjectSpace::WORD_SIZE?

Although "word" is ambiguous, providing sizeof(long), sizeof(char*),
etc. via RbConfig
with clear names seems good feature:
RbConfig["sizeof(long)"], RbConfig["sieof(char*)"],
RbConfig["sizeof(time_t)"], ...

Tanaka Akira

Updated by nobu (Nobuyoshi Nakada) almost 11 years ago

akr (Akira Tanaka) wrote:

Although "word" is ambiguous, providing sizeof(long), sizeof(char*),
etc. via RbConfig
with clear names seems good feature:
RbConfig["sizeof(long)"], RbConfig["sieof(char*)"],
RbConfig["sizeof(time_t)"], ...

RbConfig is a module, so RbConfig.[] doesn't seem good.
What about RbConfig::SIZEOF instead?

Updated by nobu (Nobuyoshi Nakada) almost 11 years ago

naruse (Yui NARUSE) wrote:

I'm curious for what purpose people use that size.
Pointers are not used usually in ruby, I think.

See #8553

I can't see any needs in ruby level there.

Updated by akr (Akira Tanaka) almost 11 years ago

2013/7/3 nobu (Nobuyoshi Nakada) :

RbConfig is a module, so RbConfig.[] doesn't seem good.
What about RbConfig::SIZEOF instead?

No problem.

They would be useful for ioctl and socket option.

Tanaka Akira

Updated by headius (Charles Nutter) over 10 years ago

  • Target version set to Ruby 2.1.0

Updated by nobu (Nobuyoshi Nakada) over 10 years ago

  • Status changed from Open to Closed

r42685

Actions #12

Updated by headius (Charles Nutter) over 10 years ago

nobu (Nobuyoshi Nakada) wrote:

r42685

Thanks! I do have one question, though.. are the names of the types (acquired via #type in sizes.c) guaranteed to be consistent across platforms/compilers?

Updated by nobu (Nobuyoshi Nakada) over 10 years ago

=begin
They are extracted from ((%configure.in%)) script automatically.
And ANSI/ISO C standard requires stringize operator to turn the argument into a string literal ((before)) expanding it.
=end

Updated by headius (Charles Nutter) over 10 years ago

nobu (Nobuyoshi Nakada) wrote:

=begin
They are extracted from ((%configure.in%)) script automatically.
And ANSI/ISO C standard requires stringize operator to turn the argument into a string literal ((before)) expanding it.
=end

I interpret this to mean that the names of the types should be ANSI/ISO C standard names. If that's the case, I'm satisfied.

My concern is if the type names vary across platforms; they would be much less useful if one platform reports "void*" and another platform reports "void *".

Updated by nobu (Nobuyoshi Nakada) over 10 years ago

Sorry that it's unclear.

It means that type names come from a distributed file, configure.in, so they are invariant on all platforms.
As for C standard, all names will become strings as-is, even if a type is defined by macro.

Updated by headius (Charles Nutter) over 10 years ago

Ok...so hopefully we have tests for those names and we can consider them "spec".

BTW, I'm asking because we'll want to provide the same SIZEOF hash in JRuby, and I need to know the names will be consistent and not change in the future.

Thanks!

Updated by nobu (Nobuyoshi Nakada) over 10 years ago

Almost of those names are defined by C standard or POSIX, so they won't change.
I think what names are included is not a spec, however.
New names may be added or existing names may be deleted, without any notice.

I think all I can guarantee is, in a same CRuby revision, same names are defined on all platforms where they are supported.

Actions #18

Updated by hsbt (Hiroshi SHIBATA) over 2 years ago

  • Project changed from 14 to Ruby master
  • Target version deleted (Ruby 2.1.0)
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0