Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #28022 > unrolled thread

ctypes - python2.7.3 vs python3.2.3

Back to article view | Back to comp.lang.python

Contents

  ctypes - python2.7.3 vs python3.2.3 Rolf <rolfb@personalized-books.com> - 2012-08-28 14:35 -0700
    Re: ctypes - python2.7.3 vs python3.2.3 John Gordon <gordon@panix.com> - 2012-08-28 21:51 +0000
      Re: ctypes - python2.7.3 vs python3.2.3 Jan Kuiken <jan.kuiken@quicknet.nl> - 2012-08-29 23:25 +0200
        Re: ctypes - python2.7.3 vs python3.2.3 John Gordon <gordon@panix.com> - 2012-09-07 19:04 +0000
    Re: ctypes - python2.7.3 vs python3.2.3 MRAB <python@mrabarnett.plus.com> - 2012-08-28 22:59 +0100

#28022 — ctypes - python2.7.3 vs python3.2.3

ctypes works as I would expect with python2.7.3.

However, when I upgrade to python3.2.3 things don't seem to work right. Look below for details.

I am not sure where I am going wrong.

Shared Library
==============
#include <stdint.h>
#include <string.h>

extern "C"
{
   int main();
   uint32_t myfunction (char **);
}

uint32_t myfunction (char ** _mydata)
{
   char mydata[16];

   strcpy(mydata, "Hello Dude!");

   *_mydata = mydata;

   return 0;
}

int main()
{
   return 0;
}

Python 2.7.3 which works as I would expect
==========================================
> python2.7 -V
Python 2.7.3

> cat py27.py
#!/usr/bin/env python2.7

from __future__ import print_function
from __future__ import unicode_literals

from ctypes import *

lib = CDLL('libtest.so')
o_result = c_char_p()
lib.myfunction(pointer(o_result))
print(repr(o_result.value))

> ./py27.py
'Hello Dude!'

Python 3.2.3 return string gets mangled
=======================================
> python3 -V
Python 3.2.3

> cat py3.py
#!/usr/bin/env python3

from ctypes import *

lib = CDLL('libtest.so')
o_result = c_char_p()
lib.myfunction(pointer(o_result))
print(repr(o_result.value))

> ./py3.py
b'\xd8\xb0y\to Dude!'

Every time I run it, I get a different set of values.

[toc] | [next] | [standalone]

#28023

In <18eb8025-7545-4d10-9e76-2e41deaadb69@googlegroups.com> Rolf <rolfb@personalized-books.com> writes:

> uint32_t myfunction (char ** _mydata)
> {
>    char mydata[16];

>    strcpy(mydata, "Hello Dude!");

>    *_mydata = mydata;

>    return 0;
> }

mydata is an auto variable, which goes out of scope when myfunction()
exits.  *_mydata ends up pointing to garbage.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#28073

On 8/28/12 23:51 , John Gordon wrote:
> In <18eb8025-7545-4d10-9e76-2e41deaadb69@googlegroups.com> Rolf <rolfb@personalized-books.com> writes:
>
>> uint32_t myfunction (char ** _mydata)
>> {
>>     char mydata[16];
>
>>     strcpy(mydata, "Hello Dude!");
>
>>     *_mydata = mydata;
>
>>     return 0;
>> }
>
> mydata is an auto variable, which goes out of scope when myfunction()
> exits.  *_mydata ends up pointing to garbage.
>

I'm not completely sure, but i think this can be solved by using:

     static char mydata[16];

(Btw.: I don't know why you use char ** _mydata, i would use
        char * _mydata, but then again, i'm not very familiar with
        ctypes)

Jan Kuiken

[toc] | [prev] | [next] | [standalone]

#28704

In <9a74$503e88dd$546bb230$30836@cache80.multikabel.net> Jan Kuiken <jan.kuiken@quicknet.nl> writes:

> >> uint32_t myfunction (char ** _mydata)
> >> {
> >>     char mydata[16];
> >
> >>     strcpy(mydata, "Hello Dude!");
> >
> >>     *_mydata = mydata;
> >
> >>     return 0;
> >> }
> >
> > mydata is an auto variable, which goes out of scope when myfunction()
> > exits.  *_mydata ends up pointing to garbage.

> I'm not completely sure, but i think this can be solved by using:

>      static char mydata[16];

That will solve the immediate problem, however it makes myfunction()
non-reentrant.

> (Btw.: I don't know why you use char ** _mydata, i would use
>         char * _mydata, but then again, i'm not very familiar with
>         ctypes)

He uses char **_mydata because he wants myfunction()'s caller to see the
new value of _mydata, which it wouldn't if it were just char *_mydata.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#28024

On 28/08/2012 22:35, Rolf wrote:
> ctypes works as I would expect with python2.7.3.
>
> However, when I upgrade to python3.2.3 things don't seem to work right. Look below for details.
>
> I am not sure where I am going wrong.
>
> Shared Library
> ==============
> #include <stdint.h>
> #include <string.h>
>
> extern "C"
> {
>     int main();
>     uint32_t myfunction (char **);
> }
>
> uint32_t myfunction (char ** _mydata)
> {
>     char mydata[16];
>
>     strcpy(mydata, "Hello Dude!");
>
>     *_mydata = mydata;
>
>     return 0;
> }
>
> int main()
> {
>     return 0;
> }
>
[snip]
What you're doing in 'myfunction' looks wrong to start with. It's
returning the address of the local array 'mydata' which allocated on
the stack when the function is entered. When the function is left it's
deallocated, so the address becomes a dangling pointer. That it gave a
reasonable result with Python 2.7.3 is down to pure luck.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web