Minero Aoki suggested that ‘instruby.rb’ should make umask to
be 0022, and this suggestion was accepted.
[ruby-dev:19801] RSTRING(str)->ptr
Nobu Nakada confirm that RSTRING(str)->ptr should be a NUL
terminated string. However, it may be NULL in ruby-1.8.x.
We must use StringValuePtr() to obtain non-NULL value.
Will rb_str2cstr be modified to use StringValuePtr(), or will extensions
have to change to get non-NULL C-strings from STR2CSTR in 1.8.0? If it
is not modified, how should extension writers write code to work on both
1.6.x and 1.8.0?
I’m guessing rb_str2cstr will have to change, since
strlen(RSTRING(str)->ptr) will break if RSTRING(str)->ptr is NULL.
In what conditions will RSTRING(str)->ptr be NULL?
Paul
···
On Mon, Mar 17, 2003 at 12:48:46AM +0900, Takaaki Tateishi wrote:
[ruby-dev:19801] RSTRING(str)->ptr
Nobu Nakada confirm that RSTRING(str)->ptr should be a NUL
terminated string. However, it may be NULL in ruby-1.8.x.
We must use StringValuePtr() to obtain non-NULL value.
Nobu Nakada confirm that RSTRING(str)->ptr should be a NUL
terminated string. However, it may be NULL in ruby-1.8.x.
We must use StringValuePtr() to obtain non-NULL value.
Will rb_str2cstr be modified to use StringValuePtr(), or will extensions
have to change to get non-NULL C-strings from STR2CSTR in 1.8.0? If it
is not modified, how should extension writers write code to work on both
1.6.x and 1.8.0?
Signatures of rb_str2cstr() and StringValuePtr() are different.
StringValuePtr() requires lvalue in order to get rid of
possibility of dangling pointer, so extensions should change to
use latter.
I’m guessing rb_str2cstr will have to change, since
strlen(RSTRING(str)->ptr) will break if RSTRING(str)->ptr is NULL.
If RSTRING(str)->ptr is NULL, RSTRING(str)->len is always 0.
In what conditions will RSTRING(str)->ptr be NULL?
An example:
’ '.dup.rstrip.gsub(/a/, ‘’)
···
At Tue, 18 Mar 2003 01:15:53 +0900, Paul Brannan wrote:
Will rb_str2cstr be modified to use StringValuePtr(), or will extensions
have to change to get non-NULL C-strings from STR2CSTR in 1.8.0? If it
is not modified, how should extension writers write code to work on both
1.6.x and 1.8.0?
Signatures of rb_str2cstr() and StringValuePtr() are different.
StringValuePtr() requires lvalue in order to get rid of
possibility of dangling pointer, so extensions should change to
use latter.
I don’t understand. Can you elaborate?
In what conditions will RSTRING(str)->ptr be NULL?
An example:
’ '.dup.rstrip.gsub(/a/, ‘’)
Why will this leave ptr NULL? It doesn’t seem very obvious from the
source (in str_gsub, ptr is set equal to buf, which is allocated with
malloc(), which should never return 0 except on error).
Why will this leave ptr NULL? It doesn't seem very obvious from the
source (in str_gsub, ptr is set equal to buf, which is allocated with
malloc(), which should never return 0 except on error).
#gsub don't match, it return rb_str_dup("") which give a NULL pointer.
Will rb_str2cstr be modified to use StringValuePtr(), or will extensions
have to change to get non-NULL C-strings from STR2CSTR in 1.8.0? If it
is not modified, how should extension writers write code to work on both
1.6.x and 1.8.0?
Signatures of rb_str2cstr() and StringValuePtr() are different.
StringValuePtr() requires lvalue in order to get rid of
possibility of dangling pointer, so extensions should change to
use latter.
I don’t understand. Can you elaborate?
rb_str2cstr() calls #to_str method on non-String object and
returns its ptr but doesn’t the result String itself. So the
object would be lost at next GC. To solve this problem,
StringValue() and StringValuePtr() macros were introduced.
As you can see in ruby.h, these macros pass the address of the
argument to helper functions, therefore you can compile:
char *s = STR2CSTR(rb_inspect(Qnil));
(and cause SEGV), but cannot:
char *s = StringValuePtr(rb_inspect(Qnil));
···
At Wed, 19 Mar 2003 00:59:26 +0900, Paul Brannan wrote:
rb_str2cstr() calls #to_str method on non-String object and
returns its ptr but doesn’t the result String itself. So the
object would be lost at next GC. To solve this problem,
StringValue() and StringValuePtr() macros were introduced.