Issue #14819 has been updated by jeremyevans0 (Jeremy Evans).


IPAddr and Date are stdlib, not core, so I don't think a C-API (rb_cstr2ipaddr, rb_cstr2date) method could be added for them unless it was part of the related extensions . Date is written in C, but IPAddr is written in ruby and doesn't have a C extension. In either case, I don't believe it would work on Windows, since I don't believe Windows allows a dlopened library to call functions in another dlopened libary.

I don't think there is a macaddr library in stdlib or core, though there is a gem for it, so I don't think rb_cstr2macaddr makes sense.

The big problem with rb_cstr2time is you would have to decide which format(s) you want to support.  You would probably want a separate function per format.

I think these types of conversion methods are better implemented in C-extension gems specific to the conversions required.  For example, in sequel_pg, I have C functions for converting to Time/Date/DateTime quickly, but they are specific to PostgreSQL's date/time formats and the specific Sequel configuration in use.

----------------------------------------
Feature #14819: Efficient cstring to RVALUE typecasting for c extension gems
https://bugs.ruby-lang.org/issues/14819#change-72356

* Author: sam.saffron (Sam Saffron)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
A general pattern I notice in the PG / MySQL and other gems is a general need for a C string to RVALUE type casting.

A lot of the problem is that the libpq likes returning strings and you do not want to allocate an extra RVALUE string for an IP address or Date and so on when returning data for the data set.

The result is that many c extension gems carry around very similar code for casting C strings to dates/ip addresses and so on. 

An example of such a function is: https://github.com/ged/ruby-pg/blob/master/ext/pg_text_decoder.c#L551-L715

Ruby already provides quite a few helpers such as `rb_cstr2inum` I wonder if there are some gaps we can fill like

`rb_cstr2ipaddr` `rb_cstr2time` `rb_cstr2date` `rb_cstr2macaddr` 

Having these implementation could help reduce code carried in gems and offer a faster method for adoption of faster patterns. For the interim gems could copy and paste MRI implementation and longer term just add an #if to lean on MRI. 

An alternative "wild" idea here would be to allow Ruby code to operate in an "unsafe" way on strings that are not RVALUES yet, .NET has a similar mechanism with `unsafe`. Eg: 

```
unsafe do
  non_rvalue_string = api.getcstr
  # operate on string with a limited set of operators that only allocate on stack
  api.free non_rvalue_string
end
``` 

If the wild idea here is interesting perhaps lets open a new topic, for this purpose let's discuss `rb_cstr2ipaddr` `rb_cstr2time` `rb_cstr2date` `rb_cstr2macaddr` 


 



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>