0

I'm doing something stupid, but not seeing what... I've reduced my problem to the below (absurd) example - but it highlights where my issue is - I'm clearly not able to pass data into and/or return from, c++, coherently.

test.cpp

extern "C"
double reflect(double inp){
    return inp;
}

The above is compiled with:

g++ -c -Wall - Werror -fPIC test.cpp -o testO.o
g++ -shared -o testSO.so testO.o

Output file definitions are included only as I'd use them in real-problem

.py

import ctypes
hdl = ctypes.cdll.LoadLibrary(r"C:\Windows\path\to\testSO.so")

So, my returns

hdl.reflect(1)
>>> 1    (no ctypes conversion, but erm, OK)

hdl.reflect(1.1)
>>> Failure (this is expected)

hdl.reflect(ctypes.c_int(1))
>>> 1   (right well, c_int to c_double looks like it could implicitly work)

hdl.reflect(ctypes.c_float(1.1))
>>> 1006192077   (WTF?!?)

hdl.reflect(ctypes.c_double(1.2))
>>> 858993459    (WTF?!?!)

OS is windows 10, compiler is minGW-W64 8.1.0, python is 3.8 (anaconda)

I've ran DLLs before and I've compiled my own .c into python modules before - but for the life of me I cannot see what I'm doing wrong here.....!?!

edit: Corrected typo as pointed out by Topological Sort (path to .so was correct in code, was missing trailing " here)

Amiga500
  • 1,258
  • 1
  • 6
  • 11
  • I have no answers, but some observations of what I had to do to get this kinda working. Had to take out `-Wall`; had to change `r"C:\Windows\path\to\testSO.so` to `"./testSO.so"` (you need a trailing ", and the path can be relative). ...Then I found `hdl.reflect(1)` was returning 0. I put a line in the test.cpp file to print the parameter; it also is 0. So the problem may relate to passing in, not returning. I'm using python3, python 3.9.7, and g++ 11.2.0. – Topological Sort Feb 09 '22 at 14:37
  • Duplicate of [\[SO\]: C function called from Python via ctypes returns incorrect value (@CristiFati's answer)](https://stackoverflow.com/questions/58610333/c-function-called-from-python-via-ctypes-returns-incorrect-value/58611011#58611011) – CristiFati Feb 09 '22 at 15:11
  • Thanks Cristi, you indeed had the correct answer. – Amiga500 Feb 09 '22 at 15:35

1 Answers1

2

Object files and shared libraries do not contain any information about the types of function parameters or return types, at least not for C linkage functions.

Therefore ctypes has no way of knowing that the function is supposed to take a double argument and return a double.

If you call it with anything else than ctypes.c_double as argument, you will have undefined behavior. But you can set the argument types up for automatic conversion to the correct ctypes type (see below).

ctypes also assumes that the return type is int. If that is not the case, you are supposed to set the return types correctly before calling. In the following I also set up the argument types so that ctypes automatically uses the correct type in calls:

reflect = hdl.reflect
reflect.argtypes = [ctypes.c_double]
reflect.restype = ctypes.c_double
reflect(1.2)
user17732522
  • 53,019
  • 2
  • 56
  • 105
  • Alos note that the implicit conversion mentioned here is done by the `ctypes` package. All this has nothing to do with C/C++ implicit conversion rules. The C/C++ rules are applied at compile time not at runtime. – Jakob Stark Feb 09 '22 at 14:57
  • @JakobStark Yes, maybe I shouldn't have used the term "implicit conversion" which has a technical meaning in C and C++. I have clarified that a bit. – user17732522 Feb 09 '22 at 14:59