Bug report

Looks like posix._path_normpath has slightly different behaviour to the python implementation of normpath defined in posixpath, as such os.path.normpath behaves differently on Python 3.11 (where posix._path_normpath is used if it exists) vs 3.10 on posix systems:

Python 3.10:

>>> import os.path
>>> os.path.normpath('hello\x00world')
'hello\x00world'
>>> os.path.normpath('\x00hello')
'\x00hello'

Python 3.11:

>>> import os.path
>>> os.path.normpath('hello\x00world')
'hello'
>>> os.path.normpath('\x00hello')
'.'

Obviously filepaths shouldn't have nulls in them, but the above means invalid input to a program could result in the wrong files or directories being used, rather than an error about embedded nulls once the filepaths are actually used for a system call. And I'm guessing the inconsistency between Python3.10 and 3.11, or between the Python and C implementations of normpath was not intended in any case.

Your environment

CPython 3.11.3, running on Arch Linux

Python 3.11.3 (main, Jun 5 2023, 09:32:32) [GCC 13.1.1 20230429] on linux

Linked PRs

• gh-106242: Fix path truncation in normpath #106816
• [3.12] gh-106242: Fix path truncation in os.path.normpath (GH-106816) #107981
• [3.11] gh-106242: Fix path truncation in os.path.normpath (GH-106816) #107982
• gh-106242: Minor fixup to avoid compiler warnings #107983
• gh-106242: Make ntpath.realpath errors consistent with abspath when there are embedded nulls #108248
• [3.12] gh-106242: Make ntpath.realpath errors consistent with abspath when there are embedded nulls (GH-108248) #108251
• [3.11] gh-106242: Make ntpath.realpath errors consistent with abspath when there are embedded nulls (GH-108248) #108252