# Rationale for non-overflow checking format codes in \`PyArg\_Parse\*\` **URL:** \ **Category:** Core Development\ **Created:** [November 4, 2023, 11:01am UTC](https://discuss.python.org/t/rationale-for-non-overflow-checking-format-codes-in-pyarg-parse/37883 "2023-11-04T11:01:44Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![pitrou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pitrou/32/28_2.png) [@pitrou](https://discuss.python.org/u/pitrou)\ **Post date:** [November 4, 2023, 11:01am UTC](https://discuss.python.org/t/rationale-for-non-overflow-checking-format-codes-in-pyarg-parse/37883/1 "2023-11-04T11:01:44Z")
I was curious if someone knew about the rationale for the ages-old behavior of `PyArg_ParseTuple` format codes for unsigned integers, none of which checks for overflow (while their signed counterparts do). For example: > `h` ([`int`](https://docs.python.org/3/library/functions.html#int)) [short int] > Convert a Python integer to a C short int. > `H` ([`int`](https://docs.python.org/3/library/functions.html#int)) [unsigned short int] > Convert a Python integer to a C unsigned short int, without overflow checking. (from [Parsing arguments and building values — Python 3.12.0 documentation](https://docs.python.org/3/c-api/arg.html#numbers)) ---
**Author:** ![storchaka](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/storchaka/32/217_2.png) [@storchaka](https://discuss.python.org/u/storchaka)\ **Post date:** [November 4, 2023, 11:46am UTC](https://discuss.python.org/t/rationale-for-non-overflow-checking-format-codes-in-pyarg-parse/37883/2 "2023-11-04T11:46:08Z")
Because you do not know whether some integer type alias in C or Posix (like time\_t or gid\_t) is signed or unsigned. On different platforms it can be different. Also, when some negative values like -1 can have special meaning, the rest of values can be interpreted as unsigned.