coverage: 91.71% (+0.003%) from 91.707% when pulling 23bdc9c on span/bufcomp into 88fbc40 on master.

Maybe we could spike an abstraction over the recurring pattern of the buffer alignment code: i.e. "process data until alignment is reached, process data in buffer alignment, process remaining bytes causing disalignment"

That would be pretty nice. I've made several attempts over the years at this and never got anything that worked (ie was actually cleaner/easier to understand and did not introduce perf issues somwhere)

I've made several attempts over the years at this and never got anything that worked

Just a pure gut feeling: it might be a good playground for C++20 coroutines.

I would be concerned about using coroutines wrt baremetal systems, I don't know what degree of runtime support this requires.

I wonder for final if we should be checking the length of the span.

I deliberately didn't add checks to the private virtual add_data() and final_result() implementations. They should all be invoked via the public update() and final() calls in Buffered_Computation. Those public wrappers have asserts for the lengths where possible. Or did I miss the check somewhere?

Maybe we could replace the asserts with BOTAN_ARG_CHECK, though.

They should all be invoked via the public update() and final() calls in Buffered_Computation. Those public wrappers have asserts for the lengths where possible.

Sorry I missed this. Looks fine then.

Maybe we could replace the asserts with BOTAN_ARG_CHECK, though.

Yeah concur on this. BOTAN_ASSERT should be only for conditions where we believe it could never fail but want to double check. But BOTAN_ASSERT has been around a lot longer than BOTAN_ARG_CHECK etc and so we have a number of cases where we are using assert to check user inputs.