Support 32bit system

[sahargavriely]

So I had a problem running the line_profiler on a RPI - 32bit system.
Whenever I tried to profile a function that exceeds some time limit, the line_profiler report show negative values for time measuring variables.
I believe I have experienced this kind of behavior due to overflow.

Showcase:

foo.py:

Simulation of foo.py before the changes I represent in this PR:

Simulation of foo.py after the changes I represent in this PR:

[codecov]

Codecov Report

Merging #249 (49be615) into main (d1d1398) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #249   +/-   ##
=======================================
  Coverage   53.36%   53.36%           
=======================================
  Files          11       11           
  Lines         832      832           
  Branches      168      168           
=======================================
  Hits          444      444           
  Misses        329      329           
  Partials       59       59           

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d1d1398...49be615. Read the comment docs.

[Erotemic]

This looks reasonable, and the tests pass, but I don't think we have a 32 bit system in the test CI. Not sure if Github Actions has that as an available option.

One thing I see is tha the type of ret is PY_LONG_LONG, but a int64_t is being used to do a c-style cast on the timespec's attributes. Should this be using PY_LONG_LONG instead of int64_t? I'm not sure if they resolve to the same type, but I think it would make more sense to just make sure we are using the same name to reference the same type to prevent confusion.

My experience with low-level considerations like this is limited, so input from people with more experience would be appreciated.

[sahargavriely]

This looks reasonable, and the tests pass, but I don't think we have a 32 bit system in the test CI. Not sure if Github Actions has that as an available option.

One thing I see is tha the type of ret is PY_LONG_LONG, but a int64_t is being used to do a c-style cast on the timespec's attributes. Should this be using PY_LONG_LONG instead of int64_t? I'm not sure if they resolve to the same type, but I think it would make more sense to just make sure we are using the same name to reference the same type to prevent confusion.

My experience with low-level considerations like this is limited, so input from people with more experience would be appreciated.

Sounds reasonable.
I've added a commit to align the casting types.
(I've also compiled and tested - the same thing I did in the description - locally)

[sahargavriely]

@Erotemic I'm not an expert regarding GitHub CI, but I think that adding a arch = x86 field to the strategy matrix should do the trick.

[Erotemic]

LGTM, thanks!