Description

assignee = None
closed_at = None
created_at = <Date 2018-01-17.14:32:06.372>
labels = ['interpreter-core', 'type-bug', '3.11']
title = 'chr raises OverflowError'
updated_at = <Date 2021-11-22.15:20:54.228>
user = 'https://bugs.python.org/ukl'

activity = <Date 2021-11-22.15:20:54.228>
actor = 'mark.dickinson'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2018-01-17.14:32:06.372>
creator = 'ukl'
dependencies = []
files = ['47390']
hgrepos = []
issue_num = 32582
keywords = ['patch']
message_count = 5.0
messages = ['310178', '310180', '310288', '310330', '406721']
nosy_count = 6.0
nosy_names = ['terry.reedy', 'mark.dickinson', 'vstinner', 'serhiy.storchaka', 'ukl', 'iritkatriel']
pr_nums = ['5218']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue32582'
versions = ['Python 3.11']

Activity

1. ukl commented on Jan 17, 2018

   

   uklmannequin

   on Jan 17, 2018

   MannequinAuthor

   More actions

   Hello,

   the description for chr (from https://docs.python.org/3/library/functions.html#chr) reads as:

       Return the string representing a character whose Unicode code
       point is the integer i. [...] The valid range for the argument
       is from 0 through 1,114,111 (0x10FFFF in base 16). ValueError
       will be raised if i is outside that range.
   

   If however a value > 0x7fffffff (or < -0x80000000) is provided, the function raises an Overflow error:

           $ python3 -c 'print(chr(0x80000000))'
           Traceback (most recent call last):
             File "<string>", line 1, in <module>
           OverflowError: signed integer is greater than maximum

   This is either a documentation problem or (more like) an implementation issue. I attached a patch that fixes the issue for me. (I'm not sure however if I should call PyErr_Clear() before raising ValueError.)

   Reacted by Martin Thoma
2. ukl

   added

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   on Jan 17, 2018
3. vstinner commented on Jan 17, 2018

   

   vstinner

   on Jan 17, 2018

   Member

   More actions

   It's more an implementation issue.

   I proposed PR 5218 to also raise a ValueError on overflow.

   I propose to only change Python 3.7, and only Python 2.7 and 3.6 unchanged.
4. vstinner

   added

   3.7 (EOL)end of lifeend of life

   on Jan 17, 2018
5. terryjreedy commented on Jan 19, 2018

   

   terryjreedy

   on Jan 19, 2018

   Member

   More actions

   The message I get on Windows is
   OverflowError: Python int too large to convert to C long

   Given that the exception type is documented, making this a clear bug, I would be tempted to fix in 3.6 also. But your decision.
6. serhiy-storchaka commented on Jan 20, 2018

   

   serhiy-storchaka

   on Jan 20, 2018

   Member

   More actions

   Perhaps this issue should be raised on Python-Dev, since it changes the old and well-known behavior of buildins. I think that ValueError is more appropriate, but in past we decided to keep OverflowError for compatibility.

   If change chr(), other code needs to be changed. "%c", PyUnicode_FromOrdinal(), PyUnicode_Format(), and possible the same for bytes.

   See also bpo-29833 and bpo-15988.
7. iritkatriel commented on Nov 21, 2021

   

   iritkatriel

   on Nov 21, 2021

   Member

   More actions

   Still raising OVerflowError on 3.11:

   >>> print(chr(0x80000000))
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   OverflowError: Python int too large to convert to C int
8. iritkatriel

   added

   3.11only security fixesonly security fixes

   and removed

   3.7 (EOL)end of lifeend of life

   on Nov 21, 2021
9. AlexWaygood

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Nov 21, 2021
10. ezio-melotti

    transferred this issue fromon Apr 10, 2022
11. furkanonder

    added a commit that references this issue on May 14, 2023

    Merge branch 'main' into pythongh-76763

    f8c9931
12. netbsd-srcmastr

    added a commit that references this issue on Jan 14, 2024

    py-w3lib: updated to 2.1.2

    3ea0ae1
13. serhiy-storchaka

    added a commit that references this issue on Feb 1, 2024

    pythongh-76763: Make chr() always raising ValueError for out-of-range…

    d415909
14. hauntsaninja commented on Feb 4, 2024

    

    hauntsaninja

    on Feb 4, 2024

    Contributor

    More actions

    Given that this is a long standing behaviour and there's little reason to be passing large values here, should we just document that chr can raise OverflowError?

    Also note "%c" % 1114113 raises OverflowError, should that raise ValueError instead?
15. serhiy-storchaka

    added a commit that references this issue on Feb 10, 2024

    gh-76763: Make chr() always raising ValueError for out-of-range values (

    e2c4038
16. serhiy-storchaka

    added

    3.13only security fixesonly security fixes

    and removed

    3.11only security fixesonly security fixes

    on Feb 10, 2024
17. serhiy-storchaka

    closed this as completedon Feb 10, 2024
18. vstinner commented on Feb 12, 2024

    

    vstinner

    on Feb 12, 2024

    Member

    More actions

    Also note "%c" % 1114113 raises OverflowError, should that raise ValueError instead?

    To clarify for myself, with change e2c4038, chr() no longer raises OverflowError, but always raises ValueError.

    @serhiy-storchaka updated the old change on the main branch and merged it.
19. fsc-eriker

    added a commit that references this issue on Feb 14, 2024

    pythongh-76763: Make chr() always raising ValueError for out-of-range…

    f7d2872

Issue actions