From: Laurent Sansonetti <laurent.sansonetti@...>
Date: 2008-03-15T10:18:11+09:00
Subject: Re: RARRAY_PTR

Hi,

On Fri, Mar 14, 2008 at 6:03 PM, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
> Hi,
>
>  At Sat, 15 Mar 2008 09:40:15 +0900,
>  Laurent Sansonetti wrote in [ruby-core:15909]:
>
> > I think this macro is dangerous because it exposes too much internals.
>
>  You mean it has no boundary check?
>

Yes, but also this macro assumes that RArray is implemented with a
regular C buffer.

>  > Also, it is difficult to re-implement RArray using a different storage
>  > structure and efficiently support this macro at the same time. In
>  > MacRuby I am working on a new implementation of the Array class and
>  > will not be able to support this macro for inline modifications.
>
>  What kind of structure?
>

This one: http://developer.apple.com/documentation/CoreFoundation/Reference/CFArrayRef/Reference/reference.html

It's actually a complex type, that mutates from one storage structure
to another at runtime.

(The purpose of this change is to provide the ability of exchange
arrays from Ruby and Objective-C worlds without requiring any
conversion, for best performance.)

>  > I therefore suggest to introduce the following macros:
>  >
>  >   RARRAY_GET_AT(ary, idx) ...
>  >   RARRAY_SET_AT(ary, idx, value) ...
>
>  I thought another macro, RARRAY_AT(ary, idx) which ensures ary
>  has extent enough for idx and returns the corresponding
>  pointer.  This would solve your first issue, but I'm not sure
>  about the second.
>

That would work for read access, but not for write access I guess.

>  In extensions, we often have needed some VALUEs' area, instead
>  just getting from/setting to an entry.
>

From a quick grep of RARRAY in the ext directory, at a glance
RARRAY_PTR doesn't seem to be used to set entries, but only to get
them.

So maybe RARRAY_AT is enough?

Laurent