Increase coverage of base64

[leecannon]

BPO	30493
Nosy	@serhiy-storchaka, @leecannon, @ZackerySpytz
PRs	bpo-30493: Increase base64 coverage #1837 gh-74678: Increase base64 test coverage #21913

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2017-05-27.20:45:48.137>
labels = ['3.7', 'type-feature', 'tests']
title = 'Increase coverage of base64'
updated_at = <Date 2020-08-18.00:20:47.839>
user = 'https://github.com/leecannon'

bugs.python.org fields:

activity = <Date 2020-08-18.00:20:47.839>
actor = 'ZackerySpytz'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Tests']
creation = <Date 2017-05-27.20:45:48.137>
creator = 'leecannon'
dependencies = []
files = []
hgrepos = []
issue_num = 30493
keywords = ['patch']
message_count = 3.0
messages = ['294611', '294614', '294646']
nosy_count = 3.0
nosy_names = ['serhiy.storchaka', 'leecannon', 'ZackerySpytz']
pr_nums = ['1837', '21913']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue30493'
versions = ['Python 3.7']

Linked PRs

• [3.11] gh-74678: Increase base64 test coverage (GH-21913) #113810
• [3.12] gh-74678: Increase base64 test coverage (GH-21913) #113811

[leecannon]

Added tests to ensure a85decode correctly handles the 'y' character within the byte like object when foldspaces is true.

While attempting to increase coverage I found two lines of code within base64.py that appear to never execute:

• line 472
• line 501

Line 472:
The only time the TypeError except block (line 467) executes is when _b85dec[c] resolves to None for one of the c (characters) in chunk.

Then within the except block the c (characters) within chunk are iterated through until the None is hit then a ValueError is raised (line 470). Making it impossible for line 472 to execute.

Line 501:
s is assigned a value in the expression s = input.read(MAXBINSIZE) (line 494), due to this len(s) is only ever not equal to MAXBINSIZE if the end of input has been reached and nothing was read or the last chunk of data was read from input which has a len less than MAXBINSIZE but non-zero.

Therefore the only way to enter into the while loop (line 497) is if there are no more characters left to be read from input, yet all that happens in the while loop is the read function is called on input with a non zero parameter (MAXBINSIZE-len(s) must be greater than zero for the while to have executed) then when it returns nothing (it always will) execution breaks out of the while loop without modifiying s.

[serhiy-storchaka]

Please don't change the code of base64. It is correct.

1. Python is a dynamically-typed language. Arbitrary exceptions can be raised in unexpected places. For example TypeError can be raised if b[i:i + 5] return non-iterable object.

2. read(n) of unbuffered object (like sys.stdin.buffer.raw or socket) can return less than n bytes.

[leecannon]

Suggested changes have been applied to the PR.