[gnutls-devel] GnuTLS | Refactor `_gnutls_buffer_pop_prefix*` (!2121)

(Deprecated) Read-only notification of GnuTLS library development activities gnutls-devel at lists.gnutls.org
Thu Aug 6 12:51:22 CEST 2026




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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20260806/4c751653/attachment-0001.html>


More information about the Gnutls-devel mailing list