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_h an,0x0140,'abcd ')

if (PyArg_ParseTup le(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]

Re: Extention Woes

"Tuvas" wrote:
[color=blue]
> 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_h an,0x0140,'abcd ')
>
> if (PyArg_ParseTup le(args("iiz#", &can_han,&com,& data,&len)
> return NULL;[/color]

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...
[color=blue]
> 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?[/color]

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

</F>

[Dave Brueck]

Re: Extention Woes

Tuvas wrote:[color=blue]
> I am in the process of writing an extention module, and am coming up
> with lots of problems.[/color]

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]

Re: Extention Woes

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_Parse Tuple(args,"iiz #",&can_han,&co m,&dat,&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_h an,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]

Re: Extention Woes

Forgot, var declartions

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

[Neal Norwitz]

Re: Extention Woes

Tuvas wrote:[color=blue]
> Forgot, var declartions
>
> int can_han;
> int com;
> char len;
> char dat[8];[/color]

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]

Re: Extention Woes

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]

Re: Extention Woes

"Tuvas" wrote:
[color=blue]
> 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.[/color]

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).
[color=blue]
> Anyways, I tried making the changes, similar results.[/color]

post the new code and the output it's giving you.
[color=blue]
> BTW, it doesn't give me one single warning, so I don't think it's a
> casting problem...[/color]

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]

Re: Extention Woes

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!