This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: GCC overflow warnings (format-overflow, stringop-overflow)
Type: compile error Stage:
Components: Build Versions: Python 3.10, Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: christian.heimes, ncoghlan
Priority: normal Keywords:

Created on 2020-06-12 07:14 by christian.heimes, last changed 2022-04-11 14:59 by admin.

Messages (2)
msg371335 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2020-06-12 07:14
I'm getting a couple of compiler warnings with gcc-10.1.1 (Fedora 32) with an asan and ubsan build:

Parser/string_parser.c: In function ‘decode_unicode_with_escapes’:
Parser/string_parser.c:100:17: warning: null destination pointer [-Wformat-overflow=]
  100 |                 sprintf(p, "\\U%08x", chr);
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~
Parser/string_parser.c:100:17: warning: null destination pointer [-Wformat-overflow=]
Parser/string_parser.c:100:17: warning: null destination pointer [-Wformat-overflow=]

Objects/unicodeobject.c: In function ‘xmlcharrefreplace’:
Objects/unicodeobject.c:849:16: warning: null destination pointer [-Wformat-overflow=]
  849 |         str += sprintf(str, "&#%d;", PyUnicode_READ(kind, data, i));
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Objects/unicodeobject.c:849:16: warning: null destination pointer [-Wformat-overflow=]
Objects/unicodeobject.c:849:16: warning: null destination pointer [-Wformat-overflow=]

In function ‘assemble_lnotab’,
    inlined from ‘assemble_emit’ at Python/compile.c:5697:25,
    inlined from ‘assemble’ at Python/compile.c:6036:18:
Python/compile.c:5651:19: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
 5651 |         *lnotab++ = k;
      |         ~~~~~~~~~~^~~
msg380493 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2020-11-07 05:56
I *think* the lnotab one is the compiler failing to detect that the pointer has been updated to point inside the body of a Python object, but I'm also not 100% sure that it's a false alarm.
History
Date User Action Args
2022-04-11 14:59:32adminsetgithub: 85124
2020-11-07 05:56:33ncoghlansetnosy: + ncoghlan
messages: + msg380493
2020-06-12 07:14:45christian.heimescreate