I am correcting my message to add the following. Formerly, short writes by the push callback were allowed to be followed by another try by GNUTLS. Current GNUTLS release stops the tries after seeing the first short write. This means the callback is no longer following the "send()" paradigm, i.e. the callback itself is expected to wait even though it has written some portion of the requested buffer (but not all of it). send() returns immediately once at least one byte has been sent (and any remaining portion would have caused the blocking).
I was wrong saying that gnutls_record_send() used to return after a short write. It did not -- but since the loop "while (left > 0)" was only broken if the callback returned -1, it let the callback to manage waiting for the output device if it was not ready _prior_ to output, not after it. Anton Lavrentiev Contractor NIH/NLM/NCBI > -----Original Message----- > From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] > Sent: Thursday, June 12, 2014 4:28 PM > To: [email protected] > Subject: Regression bug between 2.x and 3.2? > > Hello, > > Our code is using gnutls_transport_set_{push|pull}_function() and is > having problems since > we've switched from an old GNUTLS 2.4.2 to newer 3.2.13. Namely, when > the push callback > experiences a short write (i.e. reporting fewer written bytes than it > was requested to > write), gnutls_record_send() returns an error, rather than the number of > bytes that > it has succeeded to write before the underlying short write (and which > it used to do formerly). > > Is that the expected behavior? gnutls_record_send() seems to be > documented to be able > to return a partial write. > > Anton Lavrentiev > Contractor NIH/NLM/NCBI _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
