Feature #13381: [PATCH] Expose rb_fstring and its family to C extensions

• Status: Assigned
• Priority: Normal
• Assignee: -
• Target version: -

[eagletmt (Kohei Suzuki)]

https://github.com/ruby/ruby/pull/1559

Currently, C extensions cannot use fstrings. I'd like to use
rb_fstring_cstr instead of rb_str_new_cstr for static strings in C
extensions to avoid excess allocation.

I think there's several use cases.

• https://github.com/k0kubun/hamlit/blob/v2.8.0/ext/hamlit/hamlit.c#L508-L512
• https://bitbucket.org/ged/ruby-pg/src/e5eb92cca97abc0c6fc168acfad993c2ad314589/ext/pg_connection.c?at=v0.20.0&fileviewer=file-view-default#pg_connection.c-3679
• https://bitbucket.org/ged/ruby-pg/src/e5eb92cca97abc0c6fc168acfad993c2ad314589/ext/pg_copy_coder.c?at=v0.20.0&fileviewer=file-view-default#pg_copy_coder.c-38

[ko1 (Koichi Sasada)]

• Status changed from Open to Feedback

I can understand use cases but we shouldn't expose the name "fstring".

[eagletmt (Kohei Suzuki)]

OK, I've read comments of #13077.

What do you think of renaming fstring to "deduped" string? "Deduped" strings are implicitly frozen.

• Rename rb_fstring to rb_str_deduped
• Rename rb_fstring_new to rb_str_deduped_new
• Rename rb_fstring_cstr to rb_str_deduped_cstr
• Rename rb_fstring_enc_new to rb_enc_str_deduped_new
• Rename rb_fstring_enc_cstr to rb_enc_str_deduped_cstr
  • I think enc should come first for consistency

[ko1 (Koichi Sasada)]

• Assignee set to ko1 (Koichi Sasada)
• Status changed from Feedback to Assigned

[nobu (Nobuyoshi Nakada)]

• Assignee deleted (ko1 (Koichi Sasada))

How about fixed_str?

[k0kubun (Takashi Kokubun)]

• Has duplicate Feature #16029: Expose fstring related APIs to C-extensions added

[ko1 (Koichi Sasada)]

Nobu and I discussed the name, we want to choose rb_str_pool terminology.

• rb_str_pool prefix

  • rb_str_pool(VALUE)
  • rb_str_pool_buff(const char *ptr, long len)
  • rb_str_pool_cstr(const char *ptr)
  • rb_enc_str_pool_buff(const char *ptr, long len, rb_encoding *enc)
  • rb_enc_str_pool_cstr(const char *ptr, rb_encoding *enc)

• FYI: rb_str_new series:

  • rb_str_new(const char *ptr, long len)
  • rb_str_new_cstr(const char *ptr)
  • rb_enc_str_new(const char *ptr, long len, rb_encoding *enc)
  • rb_enc_str_new_cstr(const char *ptr, rb_encoding *enc)

If there is no comments, we will merge it soon.

[Eregon (Benoit Daloze)]

I'd suggest buff => buffer, I don't think it's worth abbreviating that.
BTW, there is rb_alloc_tmp_buffer so buff would be inconsistent.

Is rb_str_pool(VALUE) useful?
I think it could be rb_str_uminus() (or just rb_funcall(str, rb_intern("-@"))).
And then we could be consistent with rb_str_new*, and drop confusing _buff suffixes (not really buffer (=> sounds mutable), just a C string with known length).

So I think this is better:

rb_str_uminus(VALUE) // or just rb_funcall(str, rb_intern("-@"))
rb_str_pool(const char *ptr, long len)
rb_str_pool_cstr(const char *ptr)
rb_enc_str_pool(const char *ptr, long len, rb_encoding *enc)
rb_enc_str_pool_cstr(const char *ptr, rb_encoding *enc)

[nobu (Nobuyoshi Nakada)]

ko1 (Koichi Sasada) suggests rb_str_pool_value(VALUE) for the first type.

As these may not create a new object, I thought of using pool as a verb instead of new however, it doesn't feel fit much.
Does anyone have other ideas?

[byroot (Jean Boussier)]

Does anyone have other ideas?

A common term for this in intern / interning / interned. However that terminology is already used for symbols (rb_str_intern).

This would look like:

rb_interned_str(VALUE)
rb_interned_str(const char *ptr, long len)
rb_interned_str_cstr(const char *ptr)
rb_enc_interned_str(const char *ptr, long len, rb_encoding *enc)
rb_enc_interned_str_cstr(const char *ptr, rb_encoding *enc)

[ko1 (Koichi Sasada)]

However that terminology is already used for symbols (rb_str_intern).

Yes. This is why we didn't propose it.

[naruse (Yui NARUSE)]

• Related to Feature #17147: New method to get frozen strings from String objects added