[gnutls-devel] GnuTLS | bug in gnutls_init() (#1414)

[Read-only notification of GnuTLS library development activities]

GitLab Support Bot commented:


> New response for issue #1414:
>
> Author: Daiki Ueno
>
> For applications that target newer C compiler and thus do not care much about portability, I would suggest always NULL initializing those `gnutls_*_t` so it works nicely with `__attribute__((cleanup(...)))` as in:
> https://gitlab.com/dueno/quic-echo/-/blob/f21fed36f35efc3c8b3665bfbc9dbfc1482edb81/gnutls-glue.c#L268

Huh, that used 'gnutls_session_t session = NULL;', and the compiler
was happy with it.  Re-reading gnutls.h, I see that most of our
gnutls_*_t types are typedefs either for enums (no corresponding
*_init function) or as pointers to opaque struct types, as in:

 struct gnutls_session_int;
 typedef struct gnutls_session_int *gnutls_session_t;

and not completely opaque types, where it would have been written:

 typedef gnutls_session_t;

>
> That said, the proposed MR seems like a nice tightening.

In the MR, I documented zero initialization by calloc() or memset();
but if you are happy guaranteeing that 'gnutls_*_t obj = NULL' is
going to remain a valid compile-time initialization (that is, we can
no longer change the typedefs to be anything other than a pointer to a
type), that's an easy tweak or followup to the MR as currently posted.

<details><summary>...</summary>

On Tue, Oct 25, 2022 at 05:15:03AM +0000, Daiki Ueno (@dueno) wrote:

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

</details>

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1414#note_1148054059
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/20221025/c8afd412/attachment.html>