> Once again: > - This PR *recognizes* the fact that special cases do in fact *exist*.
??? Is there application that heavily relies on some specific overlap percentage? > - The EVP layer has to be more aware of special cases anyhow. Where does it come from? Why does it *have to* be more aware of special cases? There is one special case that we support, fully overlapping buffer, and that's it, it doesn't *have to* be more than that. Besides, EVP is *generalized* layer and is not supposed to make overly specific assumptions. While in order to support suggested cases and the suggested way, you'll be forced to make an assumption about underlying cipher. Specifically that it processes blocks in ascending memory order, i.e. from lower to higher addresses. Once again, all our implementations do that, but *generalized* EVP layer is not the right spot to assume that they actually do. > - The test coverage of error cases is not perfect, but I try to > improve that. > - I don't see why we can't relax a check in cases that are known to > work, especially when test cases are added at the same time. Because we don't have to. Because goal is not to provide maximum flexibility, but maximum *robustness*. Well, it's not entirely true, because robustness is not the only goal, but it's not inappropriate to say that complexity has to be justified by something beside sheer why-not. _______________________________________________ openssl-project mailing list firstname.lastname@example.org https://mta.openssl.org/mailman/listinfo/openssl-project