[gnutls-devel] GnuTLS | ktls: API (!1477)
Read-only notification of GnuTLS library development activities
gnutls-devel at lists.gnutls.org
Tue Nov 30 14:56:45 CET 2021
Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1477 was reviewed by Daiki Ueno
--
Daiki Ueno started a new discussion on lib/includes/gnutls/socket.h: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_747834605
> unsigned int flags);
>
> +int gnutls_transport_is_ktls_enabled(gnutls_session_t session);
`unsigned` might be better?
--
Daiki Ueno started a new discussion on lib/system/ktls.h: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_747834608
> + KTLS_RECV = 1,
> + KTLS_SEND,
> + KTLS_DUPLEX,
If these are used as flags, I'd define them more explicitly as:
```suggestion:-2+0
KTLS_RECV = 1 << 0,
KTLS_SEND = 1 << 1,
KTLS_DUPLEX = KTLS_RECV | KTLS_SEND,
```
--
Daiki Ueno started a new discussion on lib/system/ktls.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_747834613
> + if (setsockopt (sockin, SOL_TLS, TLS_RX,
> + &crypto_info, sizeof (crypto_info))) {
> + session->internals.ktls_enabled ^= KTLS_RECV;
The intent of this XOR is to reset the `KTLS_RECV` flag, right? If `ktls_enabled` is `KTLS_SEND` (i.e., setsockopt(TLS_ULP) has failed for TLS_RX), this will actually set `KTLS_RECV`.
I'd suggest using the `lhs &= ~rhs` idiom to reset a bit flag.
--
Daiki Ueno started a new discussion on lib/system/ktls.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477#note_747834615
> + * Returns: 1 for enabled, 0 otherwise
> *
> * Since: 3.7.2
Bump to 3.7.3.
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1477
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20211130/0d943565/attachment-0001.html>
More information about the Gnutls-devel
mailing list