You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The CURLOPT_READFUNCTION function payload_source used in many SMTP/IMAP examples depend on the specific implementation details of the libcurl. The payload_source function assumes that a single large enough call to the function will be made, and that the read is large enough to fit the whole line. This directly contradicts what CURLOPT_READFUNCTION API documentation says you should do: The data area pointed at by the pointer buffer should be filled up with at most size multiplied with nitems number of bytes by your function.
While libcurl might be calling the callback in a way that makes these examples work for now, if the call pattern ever changes the example apps may cease to work or even start crashing due to buffer overflow. Even if no such change happens, the example apps should try to be as correct as possible to not proliferate incorrect and/or unsafe API usage.
I expected the following
The example app implementing CURLOPT_READFUNCTION as documented: return maximum size * nmemb bytes and keep track of the "read" position.
The text was updated successfully, but these errors were encountered:
The same callback code is used in:
It should not assume that it can copy full lines into the buffer as it
will encourage sloppy coding practices. Instead use byte-wise logic and
check/acknowledge the buffer size appropriately.
Reported-by: Harry Sintonen