This looks like something that could use test cases.

This is difficult to test because the failing code path is only entered when the input length
is larger than MAXBITCHUNK / EVP_MAXBLOCKSIZE.

for AES / camellia we have:
# define MAXBITCHUNK ((size_t)1<<(sizeof(size_t)*8-4))
for most other ciphers we have:
# define EVP_MAXCHUNK ((size_t)1<<(sizeof(long)*8-2))
If that constant is lowered to say 256 bytes you can see 20-test_enc and
20-test_enc_more.t failing without this patch.

However, I think EVP_MAXCHUNK is too high if shifted up by 3 bits it will overflow.....

Disregard the last comment, the chunk size is shifted down by 3 bits.
so the input length needs to be larger than EVP_MAXBLOCKSIZE/8
to cause a problem.

So on a 32-bit target encrypting more than 2^27 bytes = 128 MB is bound to fail.

2^28, right? It's unreasonable to mount such test. So I'd say it's ready as is.

[Just in case, since it was mentioned, in case one wonders that is. What's EVP_MAXCHUNK and why does it look the way it does. It's there to reconcile the fact that EVP accepts len as size_t, while some of lower level subroutines as [signed] long :-(]

Merged to master and 1.1.0 so far.
Thanks!