Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@edge90

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@edge90, please sign the CLA. Thank you!

@csabella I have already done that once, can try again tomorrow as the system haven't picked it up.

Edit: Added my github name to bugs.python.org (should pickup my CLA now).

Pros:

• In theory strnlen() may be slightly faster than strlen(). But it is insignificant in comparison with memory management and using locale specific functions.
• The new code is slightly clearer. Perhaps.

Cons:

• strnlen() can also be slightly slower than strlen().
• strnlen() is in the POSIX standard, but not in the C standard, also it is implemented also on Windows. But it can potentially cause issues with porting Python to exotic platforms.

The current code was added by @vstinner 10 years ago and was not changed much since then. I do not think that its clearness (which is subjective) was a problem. I am inclined to close this issue.

This PR changes strlen to strnlen so no buffer overruns are made when there's no null terminator.

strlen() is only called if str[len] is '\0' (null terminator).