Re: [sleepy.penguin] [PATCH] Support for broken system without clock_gettime.

[Eric Wong <normalperson@yhbt.net>]

"Lin Jen-Shin (godfat)" <godfat@godfat.org> wrote:
> On Wed, Sep 25, 2013 at 5:05 AM, Eric Wong <normalperson@yhbt.net> wrote:
> > No worries.  Btw, do you have time to run/write more tests for the
> > kqueue code?  I think the RARRAY_PTR usage should be replaced with newer
> > RARRAY_* macros or even just rb_ary_entry in some places for 2.1.0 and
> > rbx.
> >
> > (ref: comments in https://bugs.ruby-lang.org/issues/8399)
> 
> Would be my pleasure to do so, though maybe not in a day or two.

Thanks!  Not a problem, I'm juggling a bunch of projects, too.

> On the other hand, since I only wrote some naive C extensions
> for Ruby from copying and pasting, (i.e. readline_buffer
> https://github.com/godfat/readline_buffer )

Hehe, I pretended to know C for years by copying/editing existing
code/patches until I realized one day I knew it (or at least I think I
do :)

> I don't know why sometimes the API is in the form of macro
> and sometimes in the form of function. According to my
> C experience, I would prefer to use functions.
> 
> Is there any reason why we need macros for some functions?
> To inline function calls before C99?

Yes.  There are also some reasons such as:

  DATA_PTR(foo) = bar;  /* do NOT do this with R{STRING,ARRAY}_PTR */

Sometimes, it's also easier to just do an "#ifdef MACRO" than to
write the have_* checks in mkmf (or autoconf checks).

Anyways, for arrays, I perhaps using the slightly-slower rb_ary_*
functions might be best as ko1 says:
  http://mid.gmane.org/524259E2.9020503@atdot.net

> And do we need Ruby version guards at places if some
> Ruby API is missing for older Ruby? Or just like how we
> did for clock_gettime?

I prefer guarding based on function/macro availability whenever possible.

Only in rare cases would I put version checks (e.g. a function/macro
exists, but is broken for some versions)