Performance: Review use of `assert!` about rustls

[ctz]

Sorted now. Thanks for the report.

[plietar]

Have any benchmark been done to measure the impact of these assertions ?
Intuitively, I would think they would be very negligible compared to the rest of the stuff rustls has to do.

Many of the locations are far away from where a consumer of the library's API can have any influence or control input.

I view assertions as a way to make sure internal invariants of the library are correct, not as a way to validate input. The latter should use Result instead.

This is especially important in a security oriented library, where relying on these invariants to be correct may be critical.

[ctz]

Have any benchmark been done to measure the impact of these assertions ?
Intuitively, I would think they would be very negligible compared to the rest of the stuff rustls has to do.

Yes, the benchmarks do not show any measurable performance impact of asserts.

I view assertions as a way to make sure internal invariants of the library are correct, not as a way to validate input. The latter should use Result instead.

Of course. All parsing/untrusted input handling uses Option/Result.

Most of these asserts are executable documentation of internal state -- compiling them out is OK, as they're structurally guaranteed to be true. They're useful in development though, to shake out silly bugs early.

There's also a lot of unwrap() which is equivalent to asserting internal state, but obviously cannot/should not be compiled out. But again, this is not used on untrusted input -- a remote panic is the worst non-crypto error this library could have.