Ruby C API Question

[Tristin Davis]

[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?

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

 

[Rolando Abarca]

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,

 

[Tristin Davis]

[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.

 

[Rolando Abarca]

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-L...bs_sr_1?ie=UTF8&s=books&qid=1215091542&sr=8-1
(and of course, read it )
regards,

 

[Ryan Davis]

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.

 

[Seebs]

[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.

 

[Seebs]

[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.

 

[Seebs]

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.)

 

[Ryan Davis]

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]

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.

 

[phlip]

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!

 

[Nobuyoshi Nakada]

Hi,

At Thu, 3 Jul 2008 21:48:55 +0900,
Tristin Davis 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