Issue #14819 has been updated by larskanis (Lars Kanis).


I don't think it's really helpful to have C-str to Time converters in core. Time string representation differs in various details between PG and MySQL and even more between other sources.

However while implementing the [time decoder for pg](https://github.com/ged/ruby-pg/blob/master/ext/pg_text_decoder.c#L551-L715) I wished to have a fast version of:

    rb_funcall(rb_cTime, rb_intern("new"), 7, INT2NUM(year), INT2NUM(mon), INT2NUM(day), INT2NUM(hour), INT2NUM(min), sec_and_usec_rational, INT2NUM(gmt_offset));

We have `rb_time_timespec_new(ts, offset)` since ruby-2.3, which is more than 10 times faster than the above, but it requires to convert the time to timespec first. This conversion is pretty difficult and involves some less standard functions (timegm() and mktime()) which didn't work as expected on Windows and termix/Android.

Since Ruby core has everything builtin to do the timespec conversion, it would be nice to have a public C function to create a Time object from integer values.


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

* 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>