bug#49055: 28.0.50; [PATCH] De-obfuscate gnutls_handshake loop

[Eli Zaretskii <eliz@gnu.org>]

> From: dick.r.chiang@gmail.com
> Cc: 49055@debbugs.gnu.org
> Date: Sat, 19 Jun 2021 13:34:21 -0400
> 
> >   . the gnutls_error_is_fatal call is missing from the new code
> 
> Yes, and just as well since it's redundant with `emacs_gnutls_handle_error`.

Not really, no: emacs_gnutls_handle_error does more, so the code is
not equivalent.

> >   . the negative values of 'ret' (if they are significant) aren't
> >     tested anymore
> 
> This unchanged line 626 begs to differ.
> 
> while ((ret = gnutls_handshake (state)) < 0)

Only if we accept your removal of the inner loop.  Which I don't, at
least not yet; see below.

> >   . the condition of GNUTLS_E_INTERRUPTED is tested only once, and
> >     immediately causes the outer while-loop to be abandoned
> 
> Yes, as the commit before e87e6a2 did.  You do realize I hope that e87e6a2, in
> its desire to keep the loop going under GNUTLS_E_INTERRUPTED, almost
> certainly did not intend to call `gnutls_handshake` twice when
> GNUTLS_E_INTERRUPTED was not applicable.

Oh, yes, it did intend that: the changes are explicitly so that
interrupted calls don't fail because they were interrupted, but are
retried.

> > I'd love to see some rationale for these differences.
> 
> Your skepticism is a credit to your earnestness.  However, your expert
> scrutiny is better applied to misguided commits like e87e6a2 and d84d69d.

The thing is that I understand the changes in e87e6a2, and don't
consider them misguided.  They make Emacs more reliable in the rare
situations where the TLS handshake is interrupted.

What happens with your changes if during the TLS handshake you
repeatedly and quickly press C-g several times?

Paul, I'd appreciate your views on this, please.