[gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650)

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos commented on a discussion on lib/pcert.c:

> + * Returns: On success, %GNUTLS_E_SUCCESS (0) is returned, otherwise a
> + *   negative error value.
> + *
> + * Since: 3.6.4
> + **/
> +int gnutls_pcert_import_rawpk(gnutls_pcert_st* pcert,
> +			     gnutls_pubkey_t pubkey, unsigned int flags)
> +{
> +	/* For convenience we reuse the internal pcert structure to hold
> +	 * our raw public key. By doing so we only need one certificate
> +	 * structure that can hold multiple certificate-like credential
> +	 * types.
> +	 */
> +	int ret;
> +
> +	// Check whether a valid pointer to a public key is passed

`nit` is from nit-picking. My experience with comments is that they get old and unrelated with the code. They can also be used as an excuse to write unreadable code. Good clean code shouldn't need any comments to be readable in my opinion, and you can see that in well-written projects like systemd, where the number of comments is very low, while the readability is high. The examples I mentioned the comments were actually distracting, for example:

```
//free the pointer
free(p);
```

There is no information added by the comment which cannot be inferred by reading the code. I'd expect a comment to be useful when doing something complicated, or when doing something that is not obvious by reading the code. E.g.
```
*0xff03a3 = 3;
```
needs a comment. The `free(p)` is obvious to someone in the project.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_119177846
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/20181121/b6a1683c/attachment-0001.html>