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

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

handling return codes from CTYPES

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

Contents

  handling return codes from CTYPES Steve Simmons <square.steve@gmail.com> - 2013-01-21 10:46 +0000
    Re: handling return codes from CTYPES Duncan Booth <duncan.booth@invalid.invalid> - 2013-01-21 11:11 +0000
      Re: handling return codes from CTYPES Steve Simmons <square.steve@gmail.com> - 2013-01-22 08:02 +0000
      Re: handling return codes from CTYPES Chris Angelico <rosuav@gmail.com> - 2013-01-23 00:10 +1100

#37189 — handling return codes from CTYPES

PY33, Win7, Python Newbie, Not homework:-)

I'm trying to use some 'C' DLLs from Python using ctypes and I have a 
minor issue with the return valuesbut  I am new to Python; ctypes and 
using DLLs so I am at the bottom of so many learning curves, I'm not 
sure where or how to find my mistake.
When I call the DLL, I am expecting a return of 1 (success) or a 
negative number (one of a set of error conditions)the return value is 
specified as 'short' in the DLL call specification - "short InitScanLib 
(const char * szLicense)".   What I get back is either a 1 or something 
like 65535.  This implies that I am receiving the expected value (-1) 
but 'something' is being lost in the translation.  The code is asper the 
snippet below:

 >>> from ctypes import *
 >>> sLib = cdll.slib
 >>> lic_key = c_char_p("asdfghjkl".encode(encoding='utf_8', 
errors='strict'))
 >>> initResult = sLib.InitScanLib(lic_key.value)
 >>> print("InitScanLib Result:  ", initResult)
InitScanLib Result:   65535
 >>>

I've tried declaring initResult as c_short by: inserting...

 >>> initResult = c_short(0)

... before the call to sLib.InitScanLib but I still get the same 
response (65535).

Interactively, I can see ...
 >>> c_short(65535)
c_short(-1)
 >>> c_short(-1)
c_short(-1)
 >>>

It's not a critical issue because I only want the return value to 
lookupa textual error message but I do want to understand what's going 
on. Any input appreciated.

[toc] | [next] | [standalone]

#37192

Steve Simmons <square.steve@gmail.com> wrote:

> >>> from ctypes import *
> >>> sLib = cdll.slib
> >>> lic_key = c_char_p("asdfghjkl".encode(encoding='utf_8', 
> errors='strict'))
> >>> initResult = sLib.InitScanLib(lic_key.value)
> >>> print("InitScanLib Result:  ", initResult)
> InitScanLib Result:   65535
> >>>
> 
> I've tried declaring initResult as c_short by: inserting...
> 
> >>> initResult = c_short(0)
> 
> ... before the call to sLib.InitScanLib but I still get the same 
> response (65535).

Tell the function what type to return before you call it:

InitScanLib = sLib.InitScanLib
InitScanLib.restype = c_short

See http://docs.python.org/2/library/ctypes.html#return-types

You can also tell it what parameter types to expect which will make calling 
it simpler.

-- 
Duncan Booth http://kupuguy.blogspot.com

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

#37256

Duncan, Mike, MRAB,

Thank you.  New technology set, same forgotten lesson - RTFM (all of it!).

Thanks also for the clarification on discarding objects and Garbage 
Collection.  Looks like I'll have to turn a large chunk of my previous 
understanding of (mainframe) languages 'inside out'.

I'm just wondering how often I'll have to chant "it isn't a variable, 
it's a name bound to an object" before I can write a chunk of code 
without spending ages pondering why it isn't working.

I already like Python for its clean design but I think it'll be a while 
before I love it completely.

Steve

On 21/01/2013 11:11, Duncan Booth wrote:
> Tell the function what type to return before you call it: InitScanLib
> = sLib.InitScanLib InitScanLib.restype = c_short See
> http://docs.python.org/2/library/ctypes.html#return-types You can also
> tell it what parameter types to expect which will make calling it
> simpler.

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

#37271

On Tue, Jan 22, 2013 at 7:02 PM, Steve Simmons <square.steve@gmail.com> wrote:
> Thanks also for the clarification on discarding objects and Garbage
> Collection.  Looks like I'll have to turn a large chunk of my previous
> understanding of (mainframe) languages 'inside out'.
>
> I'm just wondering how often I'll have to chant "it isn't a variable, it's a
> name bound to an object" before I can write a chunk of code without spending
> ages pondering why it isn't working.
>
> I already like Python for its clean design but I think it'll be a while
> before I love it completely.

Yeah, it takes some getting used to. I've spent the past couple of
decades writing imperative code with strict declarations and fairly
close to the metal, and I still have one C++ module at work - but more
and more, I'm pushing to write code in a modern high-level language
like Python, where memory management isn't my problem, and failings in
the code result in easily-readable (and catchable!) exceptions. I
often fire up gdb for the C++ code at work, but usually a Python or
Pike exception traceback is enough on its own.

Learning curve, rewarded with immensely easier work. So many things
are like that; life is all about figuring out which ones are worth the
curve's effort.

ChrisA

[toc] | [prev] | [standalone]

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

csiph-web