Rust Cpython ffi

[feral halo]

C's int is usually exactly the same as Rust's i32

By which I mean "on some weird platforms it may not be, but 99% of the time it is"

Are you running on some strange embedded platform?

If not, then no, you're not in the 1%

If you want to be sure, use libc::c_int instead of i32, it's a type alias for whatever type corresponds to C's int

That isn't a platform.

What kind of hardware does your program run on? "normal" computers, or things like arduinos or other microcontrollers

[calm geyser]

So um, why are we not using pyo3?

[feral halo]

Unless it's microcontrollers, int is i32

[feral halo]

Also this, yes

[calm geyser]

Welp, my condolences

[feral halo]

Gonna be entirely honest, the fact you're confused about the size of C's int makes me think you've probably missed some other subtle point and made a mistake elsewhere

I'm not qualified to be sure, though

[warped tulip]

are you sure there isn't an error? functions like that return -1 as an error sentinel

you should read the documentation before calling ffi functions: https://docs.python.org/2/c-api/int.html#c.PyInt_AsLong

[feral halo]

If there is an error, -1 is returned, and the caller should check PyErr_Occurred() to find out whether there was an error, or whether the value just happened to be -1.
Ah yes, C APIs

The thing is, a C string is not the same as a Rust string, but a C int is (nearly always) the same as a Rust i32

[warped tulip]

are you sure it isn't an error or do you know it isn't an error. Because your code snippet does not show you checking it

and more importantly, why are you using raw ffi functions and not the safe api that rust-cpython provides?

if you have to ask these questions you should not be using the ffi functions