Ruby C API Question

I’ve been going over the Ruby API and I have a couple questions.

Why are the variables defined outside the block? What effect does this
have
on the variables?

static VALUE
fsdbm_s_open(argc, argv, klass)
int argc;
VALUE *argv;
VALUE klass;
{
VALUE obj = Data_Wrap_Struct(klass, 0, free_sdbm, 0);

if (NIL_P(fsdbm_initialize(argc, argv, obj))) {
return Qnil;
}

if (rb_block_given_p()) {
    return rb_ensure(rb_yield, obj, fsdbm_close, obj);
}

return obj;

}

I’ve always defined my variables inside a block.

static VALUE fsdbm_s_open(argc,argv,self) {
int argc;
VALUE argv;
VALUE self
/
Etc */
}

On Jul 3, 2008, at 8:48 AM, Tristin D. wrote:

I’ve been going over the Ruby API and I have a couple questions.

Why are the variables defined outside the block? What effect does
this have
on the variables?

they are not “outside” the block, it’s just a way to define the type
of the variables in the function’s signature. This:

static VALUE
fsdbm_s_open(argc, argv, klass)
int argc;
VALUE *argv;
VALUE klass;
{

is the same as this:

static VALUE
fsdbm_s_open(int argc, VALUE *argv, VALUE klass)
{

I’ve always defined my variables inside a block.

now, I’m not sure you can do it that way…

static VALUE fsdbm_s_open(argc,argv,self) {
int argc;
VALUE argv;
VALUE self
/
Etc */
}

regards,

So its just a style thing. That answers my question. Thank you.

On Jul 3, 2008, at 05:48 , Tristin D. wrote:

Why are the variables defined outside the block? What effect does
this have
on the variables?

Because ruby-core uses the ancient K&R style function definitions.
You’re used to the almost-as-ancient ANSI style function definitions.
They’re entirely equivalent, except the latter won’t compile on
ancient C compilers. Stick to ANSI for clarity.

On 2008-07-03, Tristin D. [email protected] wrote:

[Note: parts of this message were removed to make it a legal post.]

I’ve been going over the Ruby API and I have a couple questions.

Why are the variables defined outside the block? What effect does this have
on the variables?

It’s compatibility with compilers older than about 1988. :slight_smile:

On Jul 3, 2008, at 9:12 AM, Tristin D. wrote:

So its just a style thing. That answers my question. Thank you.

btw, if you’re even considering programming in C, you MUST have a copy
of K&R:

<http://www.amazon.com/Programming-Language-Prentice-Hall-Software/dp/0131103628/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1215091542&sr=8-1

(and of course, read it :-P)
regards,

On 2008-07-03, Tristin D. [email protected] wrote:

[Note: parts of this message were removed to make it a legal post.]

So its just a style thing. That answers my question. Thank you.

No!

  1. Certain old (or intentionally underfeatured) compilers CANNOT
    compile
    with the modern style, with parameter types in the argument list.
  2. The semantics are different for some types.

If you are writing something that doesn’t have a compelling reason to be
compiled on obsolete compilers (and Ruby, sadly, does), you should NEVER
use the old style. It’s been obsolete for just shy of twenty years, and
the new style has existed for longer.

On 2008-07-03, Rolando A. [email protected] wrote:

btw, if you’re even considering programming in C, you MUST have a copy
of K&R:

Agreed.

Also, for people who want something a little easier to get into, I have
to recommend Kim King’s C Programming: A Modern Approach. I kid you
not,
I think it is probably a better book to learn C from than K&R.

(Making it the only book I’ve ever said that about.)

On 2008-07-04, Ryan D. [email protected] wrote:

Don’t get your panties so bunched up… these days it really is just a
style thing.

No. If it were “just a style thing”, there would not exist code where
the
semantics are significantly changed by choice of declaration style, but
there
does.

Now, you may think that the semantic differences don’t come up very
often,
and in some code this may be correct. However, there really is a
difference;
it is not “just a style thing”.

There is nothing Tristen will write where K&R vs ANSI
will be an issue. That is almost entirely guaranteed. If it were a
possibility, then Tristen would already know the difference because
he’d be an old suspender wearing bearded UNIX type.

There’s really no correlation there.

On Jul 3, 2008, at 17:31 , Seebs wrote:

On 2008-07-03, Tristin D. [email protected] wrote:

So its just a style thing. That answers my question. Thank you.

No!

  1. Certain old (or intentionally underfeatured) compilers CANNOT
    compile
    with the modern style, with parameter types in the argument list.
  2. The semantics are different for some types.

Don’t get your panties so bunched up… these days it really is just a
style thing. There is nothing Tristen will write where K&R vs ANSI
will be an issue. That is almost entirely guaranteed. If it were a
possibility, then Tristen would already know the difference because
he’d be an old suspender wearing bearded UNIX type.

Seebs wrote:

Now, you may think that the semantic differences don’t come up very often,
and in some code this may be correct. However, there really is a difference;
it is not “just a style thing”.

Given a K&R-compatible C implementation, this is indeed not just a style
thing:

fsdbm_s_open(argc, argv, klass)
int argc;
VALUE *argv;
VALUE klass;

I suspect it might push the 3 arguments as machine words, even if one
were
narrow, like a char. Gods only know what it could do with the pointer -
and a
VALUE is a union of pointers with scalars.

But I forget how much prototyping is required to get a C to pass chars
as chars.
Probably enough to invoke the “as if” rule. But because I know I don’t
know
this, I would not play games with method calls into Ruby’s raw C source!

Hi,

At Thu, 3 Jul 2008 21:48:55 +0900,
Tristin D. wrote in [ruby-talk:307140]:

I’ve always defined my variables inside a block.

static VALUE fsdbm_s_open(argc,argv,self) {
int argc;
VALUE argv;
VALUE self
/
Etc */
}

Probably, you might have dreamed.

$ gcc -DVALUE=‘unsigned long’ -c TristinDavis.c
TristinDavis.c: In function ‘fsdbm_s_open’:
TristinDavis.c:2: error: ‘argc’ redeclared as different kind of symbol
TristinDavis.c:1: error: previous definition of ‘argc’ was here
TristinDavis.c:3: error: ‘argv’ redeclared as different kind of symbol
TristinDavis.c:1: error: previous definition of ‘argv’ was here
TristinDavis.c:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
attribute’ before ‘}’ token