If length == 0 || *current != '=' is false, the for loop will always
end up in this same point, until the if statement becomes true.
Thus, the if statement is not needed.
case 1 is already handled in the first lines of the for loop;
it would only be entered in the invalid case where the string
continues past the defined length (ch != 0 but length-- == 0).
case 2 and case 3 are redundant, since k >= j and later the
string is truncated to j characters anyway.
If length == 0 || *current != '=' is false, the for loop will always
end up in this same point, until the if statement becomes true.
Thus, the if statement is not needed.
base64_encode used safe_emalloc, but one of the arguments was derived from a
multiplication, thus making the allocation unsafe again.
There was a size check in place, but it was off by a factor of two as it
didn't account for the signedness of the integer type.
The unsafe allocation is not exploitable, but still causes funny behavior
when the sized overflows into a negative number.
To fix the issue the *4 factor is moved into the size argument (where it is
known to be safe), so safe_emalloc can carry out the multiplication.
The size check is removed as it doesn't really make sense once safe_emalloc
works correctly. (Would only cause base64_encode to silently return false
instead of throwing an error. Also could cause problems with other uses of
the base64 encoding API, which all don't check for a NULL return value.)
Furthermore the (length + 2) < 0 check is replaced with just length < 0.
Allowing lengths -2 and -1 doesn't make sense semantically and also is not
honored in the following code (negative length would access unallocated
memory.)
Actually the length < 0 check doesn't make sense altogether, but I left it
there just to be safe.
