Extention Woes

[Tuvas]

I am in the process of writing an extention module, and am coming up
with lots of problems. Perhaps someone could be of use. I keep getting
data that isn't what I'm sending the program. Let me give the line of C
code and Python Code and output to illistrate the problem.

write_can(can_han,0x0140,'abcd')

if (PyArg_ParseTuple(args("iiz#",&can_han,&com,&data, &len)
return NULL;

Okay, so I put in a print statement to print out the variables can_han,
com, data, and length. The results were more or less this (I don't have
copy/paste at the moment, so...

1357 com->0 len->4 str->,/p.

Anways, the variable can_han was correct, the length is correct, but
the com and the string are garbage. Any ideas as to why this may be?
Thanks!

[Fredrik Lundh]

"Tuvas" wrote:

I am in the process of writing an extention module, and am coming up
with lots of problems. Perhaps someone could be of use. I keep getting
data that isn't what I'm sending the program. Let me give the line of C
code and Python Code and output to illistrate the problem.

write_can(can_han,0x0140,'abcd')

if (PyArg_ParseTuple(args("iiz#",&can_han,&com,&data, &len)
return NULL;
that doesn't look entirely correct. maybe you should switch to a com-
puter with working cut and paste, so we don't have to guess...
Okay, so I put in a print statement to print out the variables can_han,
com, data, and length. The results were more or less this (I don't have
copy/paste at the moment, so...

1357 com->0 len->4 str->,/p.

Anways, the variable can_han was correct, the length is correct, but
the com and the string are garbage. Any ideas as to why this may be?

it would help if you included the variable declarations and the exact printf
statement you used to print them.

</F>

[Dave Brueck]

Tuvas wrote:

I am in the process of writing an extention module, and am coming up
with lots of problems.

This isn't a direct answer to your question, but what sort of extension is it?
Do you need to actually write a Python extension?

I ask because I've all but stopped writing Python extension modules and just use
ctypes instead (i.e. write your module as a normal .dll or .so that exports some
functions, and then use ctypes to call them).

There are probably some cases where this approach isn't a good fit, but it has
worked really well for me for a lot of different applications.

Best of luck,
-Dave

[Tuvas]

I tried Ctypes, but it was giving me tons of problems in the install
phase, and so I decided it'd just be better to use an extention module.
It's the type of stuff that could be perfectly done with ctypes, but...
Oh well. Also, I've done all but this last little piece with
extentions, might as well finish it.

Exact stuff.
C Code (Just parsing and printing)

if(!PyArg_ParseTuple(args,"iiz#",&can_han,&com,&da t,&len))
return NULL; //This command will translate
python data to C data
printf("%i com->%i len->%i string->%s\n",can_han,com,len,dat);

Python (Just command to this function)
print write_can(can_han,0x0140,'abcd')

Output
135769704 com->0 len->4 string->t=Ø·

Output expected values for length and the number, not for the string
nor com. Ideas?

[Tuvas]

Forgot, var declartions

int can_han;
int com;
char len;
char dat[8];

[Neal Norwitz]

Tuvas wrote:

Forgot, var declartions

int can_han;
int com;
char len;
char dat[8];

That should probably be:

int len;
char *dat;

IIRC, "z" returns the internal string pointer. "#" is definitely not
going to return a char. I'm pretty sure it returns an int and not a
long.

n

[Tuvas]

Well, the point of declaring it as a char was to have it as an 8 bit
integer, as is requested later on in the program. Anyways, I tried
making the changes, similar results. The len value was always right,
the problem seems to be in this com value. BTW, it doesn't give me one
single warning, so I don't think it's a casting problem... I did a full
check, and this can_han variable is right. Hmmm... Other ideas?

[Fredrik Lundh]

"Tuvas" wrote:

Well, the point of declaring it as a char was to have it as an 8 bit
integer, as is requested later on in the program.
since ParseTuple writes an integer to the address you pass in,
that's likely to overwrite some random stuff on the stack. like-
wise, passing in a character buffer where ParseTuple expects
a pointer to a char pointer isn't going to work either (but that
only writes garbage into the buffer).
Anyways, I tried making the changes, similar results.
post the new code and the output it's giving you.
BTW, it doesn't give me one single warning, so I don't think it's a
casting problem...

the C compiler doesn't understand the ParseTuple format string,
so that doesn't mean anything. it's up to you to make sure that
the format specifiers and the pointers you pass in match.

</F>

[Tuvas]

Never mind, problem solved. The other problem I was having was I forgot
to put the .so at the end of a file, so it didn't change anything.
Thanks for all of the help!