# Conversion between Python and C integers **URL:** \ **Category:** Core Development\ **Tags:** c-api\ **Created:** [January 25, 2024, 11:39am UTC](https://discuss.python.org/t/conversion-between-python-and-c-integers/44117 "2024-01-25T11:39:47Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\ **Post date:** [January 26, 2024, 4:38pm UTC](https://discuss.python.org/t/conversion-between-python-and-c-integers/44117/3 "2024-01-26T16:38:26Z")
In my TODO list, I have an item for a few months. On Windows, the `subprocess` module seems to hang forever if a negative timeout is passed, whereas it should behave as sleep(0): non-blocking call. For example, if you pass `-1e9 second`, itโ€™s rounded to `-1 ms` which becomes `0xFFFF_FFFF` and `WaitForSingleObject()` treats this value as `INFINITE` (wait forever). The `WaitForSingleObject()` function is wrapped in `Modules/_winapi.c` which uses Argument Clinic with `milliseconds: DWORD`. And `DWORD` is defined in Argument Clinic as: `create_converter('DWORD', 'k') # F_DWORD is always "k" (which is much shorter)`. In short, `PyArg_Parse()` with `k` format (C `unsigned long`) converts silently negative numbers to positive numbers (wrap) which can lead to such _surprising_ behavior. Is it a bug? A feature? I let you decide ๐Ÿ™‚ See also [Rationale for non-overflow checking format codes in `PyArg_Parse*`](https://discuss.python.org/t/rationale-for-non-overflow-checking-format-codes-in-pyarg-parse/37883) discussion. --- _[View the full topic](https://discuss.python.org/t/conversion-between-python-and-c-integers/44117)._