Re: GnuTLS | Refactor `_gnutls_buffer_pop_prefix*` (!2121)
"\(Deprecated\) Read-only notification of GnuTLS library development activities" <[email protected]>
| Newsgroups | gmane.comp.encryption.gpg.gnutls.devel |
|---|---|
| Message-ID | <[email protected]> |
Daiki Ueno commented on a discussion on lib/hello_ext.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/2121#note_3652326297 > > _gnutls_buffer_clear(buf); > > - if ((ret = _gnutls_buffer_append_prefix(buf, 8, recv_buf->htype)) < 0) > + if ((ret = _gnutls_buffer_append_uint8(buf, recv_buf->htype)) < 0) > return gnutls_assert_val(ret); > - if ((ret = _gnutls_buffer_append_prefix(buf, 24, > - recv_buf->data.length)) < 0) > + if ((ret = _gnutls_buffer_append_uint24(buf, recv_buf->data.length)) < > + 0) > return gnutls_assert_val(ret); > if ((ret = _gnutls_buffer_append_data(buf, recv_buf->data.data, > recv_buf->data.length)) < 0) > return gnutls_assert_val(ret); That's tricky. For the "pop" functions, `_gnutls_buffer_pop_uint*` are preferred over the previous `_gnutls_buffer_pop_prefix` (with the `size_t *` argument) for type-safety, because GCC will warn if the value read does not fit in the given `uint*_t *` parameter. On the other hand, for the "append" functions, it is legitimate to pass a `uint32_t` as a `uint8_t` argument, so even if we eliminate the `_gnutls_buffer_append_prefix` function, there are still issues with truncation. I guess a reasonable middle ground is to make `_gnutls_buffer_append_uint*` to take `size_t`, but with a run-time check whether it fits in the expected type. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/2121#note_3652326297 You're receiving this email because of your account on gitlab.com. Unsubscribe from this thread: https://gitlab.com/-/namespace/17175643/sent_notifications/6-4yj4gx5qrrsv63e7ai2g1vb9a-a84t7/unsubscribe | Manage all notifications: https://gitlab.com/-/profile/notifications | Help: https://gitlab.com/help _______________________________________________ Gnutls-devel mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-devel