Probably not, unless some other code change changes the conventional fd to no block. I added it only for symmetry sake. It does not fix any currently known bug.
On February 13, 2019 9:54:12 AM PST, Andreas Metzler <ametz...@bebt.de> wrote: >On 2019-02-13 "Torrance, Douglas" <dtorra...@piedmont.edu> wrote: >> On 12/27/18 3:48 PM, Nye Liu wrote: >>> Package: wmbiff >>> Version: 0.4.31-1 >>> Severity: important >>> Tags: upstream patch > >>> If gnutls_read() or read() report EAGAIN, tlscomm_expect() fails: > >>> wmbiff/nyet comm: wrote a000 CAPABILITY >>> wmbiff/nyet comm: imap.***.***:993: expecting: * CAPABILITY >>> wmbiff/nyet comm: imap.***.***:993: gnutls error reading: Resource >temporarily unavailable, try again. >>> wmbiff/nyet imap4: unable to query capability stringwmbiff/nyet >comm: wrote a002 LOGOUT >>> wmbiff/nyet comm: imap.***.***:993: closing. > >> Thanks for the bug report and patch! I submitted the patch upstream >[1] >> and released a new version of wmbiff [2]. > >> Andreas, I've pushed a new Debian package to git [3]. Would you be >able >> to review and sponsor? > >Hello, > >I am not sure about the second part of the patch. I understand wmbiff >breaking on GNUTLS_E_AGAIN from gnutls_read, because this only started >to happen recently (with TLS1.3) on blocking sockets. > >What I do not get from my rudimentary understanding C programmimg is >the >second part, this is in the else of "if (scs->tls_state)", so, afaiui >for >non-encrypted connections. Is the change necessary there at all, is it >the right thing to retry read on EAGAIN then? > >cu Andreas > >-- >`What a good friend you are to him, Dr. Maturin. His other friends are >so grateful to you.' >`I sew his ears on from time to time, sure' -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
