When compiling Xen with GCC 14, I get a compiler warning originating from the /polarssl-x86_64/library about a memset element size mismatch:

ssl_tls.c: In function ‘ssl_session_reset’:
ssl_tls.c:1778:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
1778 |     memset( ssl->ctx_enc, 0, 128 );
|     ^~~~~~
ssl_tls.c:1779:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
1779 |     memset( ssl->ctx_dec, 0, 128 );
|     ^~~~~~

This patch introduces a build-time patch to PolarSSL that replaces the hardcoded 128 byte length with a dynamic sizeof(), thus allowing clean compilation without warnings.

Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
---
 stubdom/patches/polarssl-gcc14-memset.patch | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 stubdom/patches/polarssl-gcc14-memset.patch

diff --git a/stubdom/patches/polarssl-gcc14-memset.patch b/stubdom/patches/polarssl-gcc14-memset.patch
new file mode 100644
index 0000000000..d98664d0a8
--- /dev/null
+++ b/stubdom/patches/polarssl-gcc14-memset.patch
@@ -0,0 +1,13 @@
+--- a/library/ssl_tls.c
++++ b/library/ssl_tls.c
+@@ -1775,8 +1775,8 @@
+     memset( ssl->iv_dec, 0, 16 );
+     memset( ssl->mac_enc, 0, 32 );
+     memset( ssl->mac_dec, 0, 32 );
+-    memset( ssl->ctx_enc, 0, 128 );
+-    memset( ssl->ctx_dec, 0, 128 );
++    memset( ssl->ctx_enc, 0, sizeof( *ssl->ctx_enc) );
++    memset( ssl->ctx_dec, 0, sizeof( *ssl->ctx_dec) );
+ 
+      md5_starts( &ssl->fin_md5  );
+     sha1_starts( &ssl->fin_sha1 );
-- 
2.47.3

On 25.08.2026 20:46, Andrew Mbugua wrote:
> When compiling Xen with GCC 14, I get a compiler warning originating from the /polarssl-x86_64/library about a memset element size mismatch:
> 
> ssl_tls.c: In function ‘ssl_session_reset’:
> ssl_tls.c:1778:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
> 1778 |     memset( ssl->ctx_enc, 0, 128 );
> |     ^~~~~~
> ssl_tls.c:1779:5: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
> 1779 |     memset( ssl->ctx_dec, 0, 128 );
> |     ^~~~~~
> 
> This patch introduces a build-time patch to PolarSSL that replaces the hardcoded 128 byte length with a dynamic sizeof(), thus allowing clean compilation without warnings.

First a formal note: Commit messages want limiting to 75 characters per
line (some even say 72).

Then: You introduce a patch which isn't used anywhere. What use is such
a patch? You also ...

> Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
> ---
>  stubdom/patches/polarssl-gcc14-memset.patch | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>  create mode 100644 stubdom/patches/polarssl-gcc14-memset.patch

... introduce it in a new patches/ subdir, when all other patches live
right beneath stubdom/.

> --- /dev/null
> +++ b/stubdom/patches/polarssl-gcc14-memset.patch
> @@ -0,0 +1,13 @@
> +--- a/library/ssl_tls.c
> ++++ b/library/ssl_tls.c
> +@@ -1775,8 +1775,8 @@
> +     memset( ssl->iv_dec, 0, 16 );
> +     memset( ssl->mac_enc, 0, 32 );
> +     memset( ssl->mac_dec, 0, 32 );
> +-    memset( ssl->ctx_enc, 0, 128 );
> +-    memset( ssl->ctx_dec, 0, 128 );
> ++    memset( ssl->ctx_enc, 0, sizeof( *ssl->ctx_enc) );
> ++    memset( ssl->ctx_dec, 0, sizeof( *ssl->ctx_dec) );

Don't you mean sizeof(ssl->ctx_enc) and sizeof(ssl->ctx_dec) respectively?
Otherwise it looks like you're making a bad situation worse.

Judging from surrounding style, there also looks to be a blank missing each,
ahead of the new inner closing parenthesis.

Jan

I was at first deliberating whether to send further patches because the
current successor of PolarSSL is MbedTLS. Polarssl is now legacy & not
maintained(polarssl was acquired by ARM).
Options:
1. Continual patching/maintaining a legacy library.
2. Upgrade to MbedTLS which will require alot of API changes.

On Wed, Aug 26, 2026 at 9:33 AM Jan Beulich <jbeulich@suse.com> wrote:

> On 25.08.2026 20:46, Andrew Mbugua wrote:
> > When compiling Xen with GCC 14, I get a compiler warning originating
> from the /polarssl-x86_64/library about a memset element size mismatch:
> >
> > ssl_tls.c: In function ‘ssl_session_reset’:
> > ssl_tls.c:1778:5: warning: ‘memset’ used with length equal to number of
> elements without multiplication by element size [-Wmemset-elt-size]
> > 1778 |     memset( ssl->ctx_enc, 0, 128 );
> > |     ^~~~~~
> > ssl_tls.c:1779:5: warning: ‘memset’ used with length equal to number of
> elements without multiplication by element size [-Wmemset-elt-size]
> > 1779 |     memset( ssl->ctx_dec, 0, 128 );
> > |     ^~~~~~
> >
> > This patch introduces a build-time patch to PolarSSL that replaces the
> hardcoded 128 byte length with a dynamic sizeof(), thus allowing clean
> compilation without warnings.
>
> First a formal note: Commit messages want limiting to 75 characters per
> line (some even say 72).
>
> Then: You introduce a patch which isn't used anywhere. What use is such
> a patch? You also ...
>
> > Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
> > ---
> >  stubdom/patches/polarssl-gcc14-memset.patch | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> >  create mode 100644 stubdom/patches/polarssl-gcc14-memset.patch
>
> ... introduce it in a new patches/ subdir, when all other patches live
> right beneath stubdom/.
>
> > --- /dev/null
> > +++ b/stubdom/patches/polarssl-gcc14-memset.patch
> > @@ -0,0 +1,13 @@
> > +--- a/library/ssl_tls.c
> > ++++ b/library/ssl_tls.c
> > +@@ -1775,8 +1775,8 @@
> > +     memset( ssl->iv_dec, 0, 16 );
> > +     memset( ssl->mac_enc, 0, 32 );
> > +     memset( ssl->mac_dec, 0, 32 );
> > +-    memset( ssl->ctx_enc, 0, 128 );
> > +-    memset( ssl->ctx_dec, 0, 128 );
> > ++    memset( ssl->ctx_enc, 0, sizeof( *ssl->ctx_enc) );
> > ++    memset( ssl->ctx_dec, 0, sizeof( *ssl->ctx_dec) );
>
> Don't you mean sizeof(ssl->ctx_enc) and sizeof(ssl->ctx_dec) respectively?
> Otherwise it looks like you're making a bad situation worse.
>
> Judging from surrounding style, there also looks to be a blank missing
> each,
> ahead of the new inner closing parenthesis.
>
> Jan
>