Invalid base64 generation on ARM: extra padding in the middle of the stream! about base64 HOT 3 OPEN

The problem is that base64_encode put padding in the middle of the stream ('==').

from base64.

Hey, thanks for the report. I'm a bit baffled by this, because like you say, if the library is run inside a mutex, it should be threadsafe. In fact, it should be fairly threadsafe to start with, because the only shared mutable datastructure it uses is the codec selection structure, which is written to once on the first call. All the other functions are reentrant and do not share common data. So that can't really explain the bug.

The padding is written by base64_stream_encode_final, just before base64_encode returns. So I don't see a way in which it can insert those characters into the middle of a stream. What kind of IO is writeOutput doing? It could be that the IO is not properly flushed between threads, causing the output to be interleaved.

from base64.

Before unlocking the mutex, writeOutput adds header and trailer to the base64 data, and sends out through a socket. Now if there were incorrect flushing between threads, it shall be "all-or-nothing" fashion because of the mutex.

I'm not seeing this:
HEADER#(BASE64_1)#TRAILER HEADER#(BASE64_1)(BASE64_2)#TRAILER

But I'm seeing this:
HEADER#(BASE64_1)#TRAILER HEADER#(BASE64_2)(BASE64_3)#TRAILER

This can be easily worked around by splitting the stream at the decoder (or if there is no padding in the middle no need to split at all).

My only concern here is buffer size: I've optimized Base64Buffer to fit 4096 bytes.
Obviously it wont be able handle more data and could cause a segfault.

from base64.