On 07/01/19 13:02, Laszlo Ersek wrote: > ... Honestly, at this point, I sort of wish we just rewrote this > function from zero. The current *approach* of the function is wrong. The > function currently forms a mental image of how the input data "should" > look, and tries to parse that -- it tries to shoehorn the input into the > "expected" format. If the input does not look like the expectation, we > run into gaps here and there. > > Instead, the function should follow a state machine approach, where the > outermost loop scans input characters one by one, and makes *absolutely > no assumption* about the character that has just been found. Every UINT8 > character in the input should be checked against the full possible UINT8 > domain (valid BASE64 range, the equal sign, tolerated whitespace, and > the rest), and acted upon accordingly. > > For example, valid BASE64 characters should be accumulated into a 24-bit > value, and flushed when the latter becomes full, and also at the end of > the scanning loop. > > Counting vs. decoding can be implemented by making just the flushing > operation conditional (do not write to memory).
If time allows, I'd like to attempt contributing a version like this. Please give me a bit of time to work on that. Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#43131): https://edk2.groups.io/g/devel/message/43131 Mute This Topic: https://groups.io/mt/32238987/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
