[gnutls-devel] GnuTLS | Automatically NULLify after gnutls_free() (!923)

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Thu Feb 14 19:17:09 CET 2019

> Did you see that "gnutls_x509_crt_init: Fix dereference of NULL pointer" was a previously unrecognized NULL pointer dereference - but after setting the freed pointer to NULL, clang's scan-build detected it.

That's great.

> But back to the topic, my premises were
> - just apply when building GnuTLS
> - make it transparent, so we devs don't have to carry another macro in mind
> - do not care what about policies of outside projects which include `gnutls.h`
> - (some more technical stuff, not relevant here)
> So, the idea was to just use `gnutls_free` as we all are used to instead of adding a new macro. By doing 
> so, we can't do anything wrong or forget a new macro when changing or writing new code. It appears easy 
> and elegant. Even if someone adds an additional (and redundant) `p=NULL` after a `gnutls_free(p)`, 
> compilers would optimize it out. Clang even tells you that a previously assigned value wasn't used.
> This is why I am against adding a new macro. And exporting such is not of great use to any project.

I'm fine with it. I think though we should dedicate few sentences in `CONTRIBUTION.md` about the memory functions and describe that `gnutls_free` is a macro when used inside the library.

Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/923#note_141448342
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/20190214/4d8b14ab/attachment.html>

More information about the Gnutls-devel mailing list