Bug#968734: chiark-tcl: FTBFS with optimization level -O3 and gcc-10 on s390x

2020-08-27 Thread Ian Jackson 
Gianfranco Costamagna writes ("Bug#968734: chiark-tcl: FTBFS with optimization 
level -O3 and gcc-10 on s390x"):
> Hello, this worked too!

Thanks for checking.  I hope to upload this at some point soon.

Ian.

Bug#968734: chiark-tcl: FTBFS with optimization level -O3 and gcc-10 on s390x

2020-08-27 Thread Gianfranco Costamagna 
Hello, this worked too!

thanks

G.






Il giovedì 20 agosto 2020, 20:19:37 CEST, Ian Jackson 
 ha scritto: 





Hi.  Thanks for the report.

Gianfranco Costamagna writes ("Bug#968734: chiark-tcl: FTBFS with optimization 
level -O3 and gcc-10 on s390x"):
> Hello, In Ubuntu the package FTBFS on s390x, because of -O3, and some non 
> initialized variables.

How odd.

> This makes no sense, because the variables are passed by reference
> to the functions, but gcc is probably not smart enough to detect it.

I think it is more likely that it can see into blockcipher_prep, but
not follow the control flow.  Perhaps, for example, it doesn't know
that cht_staticerr always returns nonzero, and it thinks that those
error paths in blockcipher_prep might end up using the values in the
caller.

Instead of your suggestion, if you can easily do so, can you try
this ?

Regards,
Ian.

>From 020f536563e566c6a17eeb790d2a5e56141e2b74 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Thu, 20 Aug 2020 19:18:14 +0100
Subject: [PATCH] blockcipher_prep: Initialise out parameters to placate gcc

These are all set on the success exit path but GCC is not clever
enough to see this.

Closes: #968734
Signed-off-by: Ian Jackson 
---
crypto/crypto.c | 8 
1 file changed, 8 insertions(+)

diff --git a/crypto/crypto.c b/crypto/crypto.c
index aee2556..6efea24 100644
--- a/crypto/crypto.c
+++ b/crypto/crypto.c
@@ -252,6 +252,14 @@ static int blockcipher_prep(Tcl_Interp *ip, Tcl_Obj 
*key_obj,

  int rc;
  CiphKeyValue *key;


+  /* placate gcc, see Debian #968734 */
+  *key_r= 0;
+  *sched_r= 0;
+  *iv_r= 0;
+  *iv_lenbytes_r= 0;
+  *buffers_r= 0;
+  *nblocks_r= 0;
+
  if (data_len % alg->blocksize)
    return cht_staticerr(ip, "block cipher input not whole number of blocks",
            "HBYTES BLOCKCIPHER LENGTH");
-- 
2.20.1

Bug#968734: chiark-tcl: FTBFS with optimization level -O3 and gcc-10 on s390x

2020-08-20 Thread Ian Jackson 
Hi.  Thanks for the report.

Gianfranco Costamagna writes ("Bug#968734: chiark-tcl: FTBFS with optimization 
level -O3 and gcc-10 on s390x"):
> Hello, In Ubuntu the package FTBFS on s390x, because of -O3, and some non 
> initialized variables.

How odd.

> This makes no sense, because the variables are passed by reference
> to the functions, but gcc is probably not smart enough to detect it.

I think it is more likely that it can see into blockcipher_prep, but
not follow the control flow.  Perhaps, for example, it doesn't know
that cht_staticerr always returns nonzero, and it thinks that those
error paths in blockcipher_prep might end up using the values in the
caller.

Instead of your suggestion, if you can easily do so, can you try
this ?

Regards,
Ian.

>From 020f536563e566c6a17eeb790d2a5e56141e2b74 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Thu, 20 Aug 2020 19:18:14 +0100
Subject: [PATCH] blockcipher_prep: Initialise out parameters to placate gcc

These are all set on the success exit path but GCC is not clever
enough to see this.

Closes: #968734
Signed-off-by: Ian Jackson 
---
 crypto/crypto.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/crypto/crypto.c b/crypto/crypto.c
index aee2556..6efea24 100644
--- a/crypto/crypto.c
+++ b/crypto/crypto.c
@@ -252,6 +252,14 @@ static int blockcipher_prep(Tcl_Interp *ip, Tcl_Obj 
*key_obj,
   int rc;
   CiphKeyValue *key;
 
+  /* placate gcc, see Debian #968734 */
+  *key_r= 0;
+  *sched_r= 0;
+  *iv_r= 0;
+  *iv_lenbytes_r= 0;
+  *buffers_r= 0;
+  *nblocks_r= 0;
+
   if (data_len % alg->blocksize)
 return cht_staticerr(ip, "block cipher input not whole number of blocks",
 "HBYTES BLOCKCIPHER LENGTH");
-- 
2.20.1

Bug#968734: chiark-tcl: FTBFS with optimization level -O3 and gcc-10 on s390x

2020-08-20 Thread Gianfranco Costamagna 
Source: chiark-tcl
Version: 1.3.4
tags: patch


Hello, In Ubuntu the package FTBFS on s390x, because of -O3, and some non 
initialized variables.

This makes no sense, because the variables are passed by reference to the 
functions, but
gcc is probably not smart enough to detect it.

the following patch fixes the issue by initializing the variables.

locutus@Unimatrix05-Bionic:/tmp $ debdiff chiark-tcl_1.3.4.dsc 
chiark-tcl_1.3.4ubuntu2.dsc 
diff -Nru chiark-tcl-1.3.4/crypto/crypto.c 
chiark-tcl-1.3.4ubuntu2/crypto/crypto.c
--- chiark-tcl-1.3.4/crypto/crypto.c2020-08-17 19:09:07.0 +0200
+++ chiark-tcl-1.3.4ubuntu2/crypto/crypto.c 2020-08-20 08:44:23.0 
+0200
@@ -316,13 +316,13 @@
   HBytes_Value iv, HBytes_Value *result) {
   const BlockCipherOp *op= (const void*)cd;
   int encrypt= op->encrypt;
-  int rc, iv_lenbytes;
-  const CiphKeyValue *key;
+  int rc, iv_lenbytes = 0; 
+  const CiphKeyValue *key = NULL;
   const char *failure;
-  const Byte *ivbuf;
-  Byte *buffers;
-  const void *sched;
-  int nblocks;
+  const Byte *ivbuf = 0;
+  Byte *buffers = NULL;
+  const void *sched = NULL;
+  int nblocks = 0;
 
   if (!mode->encrypt)
 return cht_staticerr(ip, "mode does not support encrypt/decrypt", 0);
@@ -352,10 +352,10 @@
 HBytes_Value iv, HBytes_Value *result) {
   const CiphKeyValue *key;
   const char *failure;
-  const Byte *ivbuf;
-  Byte *buffers;
-  const void *sched;
-  int nblocks, iv_lenbytes;
+  const Byte *ivbuf = 0;
+  Byte *buffers = NULL;
+  const void *sched = NULL;
+  int nblocks = 0, iv_lenbytes = 0;
   int rc;
 
   if (!mode->mac)
diff -Nru chiark-tcl-1.3.4/debian/changelog 
chiark-tcl-1.3.4ubuntu2/debian/changelog
--- chiark-tcl-1.3.4/debian/changelog   2020-08-17 19:09:07.0 +0200
+++ chiark-tcl-1.3.4ubuntu2/debian/changelog2020-08-20 08:44:23.0 
+0200
@@ -1,3 +1,10 @@
+chiark-tcl (1.3.5) unstable; urgency=medium
+
+  * Initialize some variables on crypto.c to make -Werror=maybe-uninitialized
+stop erroring out on s390x with -O3 (Closes: #-1)
+
+ -- Gianfranco Costamagna   Thu, 20 Aug 2020 
08:44:23 +0200
+
 chiark-tcl (1.3.4) unstable; urgency=medium
 
   * debian/tests/control: Update to libnettle8.  Fixes DEP-8 failure.


this is an example of failure log:

s390x-linux-gnu-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror 
-O2 -Wno-pointer-sign -fno-strict-aliasing -fPIC  -I../hbytes/ 
-I/usr/include/tcl8.6 -I../base -DTCL_MEM_DEBUG -MMD -o algtables.o -c 
algtables.c
s390x-linux-gnu-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror 
-O2 -Wno-pointer-sign -fno-strict-aliasing -fPIC  -I../hbytes/ 
-I/usr/include/tcl8.6 -I../base -DTCL_MEM_DEBUG -MMD -o bcmode.o -c bcmode.c
s390x-linux-gnu-gcc -g -Wall -Wmissing-prototypes -Wstrict-prototypes -Werror 
-O2 -Wno-pointer-sign -fno-strict-aliasing -fPIC  -I../hbytes/ 
-I/usr/include/tcl8.6 -I../base -DTCL_MEM_DEBUG -MMD -o crypto.o -c crypto.c
crypto.c: In function ???cht_do_blockcipherop_e???:
crypto.c:344:3: error: ???iv_lenbytes??? may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
  344 |   cht_hb_array(result, ivbuf, iv_lenbytes);
  |   ^~~~
crypto.c:338:30: error: ???ivbuf??? may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
  338 | (encrypt ? mode->encrypt : mode->decrypt)
  | ~^~~~
  339 | (cht_hb_data(v.hb), nblocks, ivbuf, buffers, alg, encrypt, sched);
  | ~
crypto.c:338:30: error: ???buffers??? may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
crypto.c:338:30: error: ???sched??? may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
crypto.c:338:30: error: ???nblocks??? may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
crypto.c: In function ???cht_do_blockcipherop_mac???:
crypto.c:371:12: error: ???nblocks??? may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
  371 |   failure= mode->mac(cht_hb_data(), nblocks, ivbuf, buffers, alg, 
sched);
  |
^
crypto.c:371:12: error: ???sched??? may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
crypto.c:371:12: error: ???buffers??? may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
crypto.c:371:12: error: ???ivbuf??? may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors
make[2]: *** [../base/final.make:23: crypto.o] Error 1
make[2]: Leaving directory '/<>/crypto'
make[1]: *** [Makefile:15: all] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:50: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


G.