INFRA-2981 Ignore warnings about uninitialized variables in this block of code

[dsolsona]

When building a new lua-resty-waf package for Buster I found issues while compiling the decode.c file. It errors with the following

make[1]: Entering directory '/tmp/luarocks_lua-resty-waf-0.11.1-2-EALUOc/lua-resty-waf/src'
gcc -c -O3 -Wall -Werror -fpic decode.c
decode.c: In function 'js_decode':
decode.c:73:22: error: 'input[<unknown>]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      input[j] = input[i + 1 + j];
                 ~~~~~^~~~~~~~~~~
cc1: all warnings being treated as errors
make[1]: *** [Makefile:18: decode.o] Error 1
make[1]: Leaving directory '/tmp/luarocks_lua-resty-waf-0.11.1-2-EALUOc/lua-resty-waf/src'
make: *** [Makefile:71: decode] Error 2

Error: Build error: Failed building.

This compiles just fine under Debian Jessie so I'm guessing there must be a difference in the behaviour of GCC. With this change, GCC will ignore the maybe-uninitialized warnings, only for this tiny block of code, and compile just fine as seen in

root@bbbe1e186893:/data/build/lua-resty-waf# lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

root@bbbe1e186893:/data/build/lua-resty-waf# make decode
cd src/ && make
make[1]: Entering directory '/data/build/lua-resty-waf/src'
gcc -c -O3 -Wall -Werror -fpic decode.c
gcc -shared -o libdecode.so decode.o
make[1]: Leaving directory '/data/build/lua-resty-waf/src'
cp src/libdecode.so lib/

The alternative is to initialise the input variable in https://github.com/bigcommerce/lua-resty-waf/blob/bigcommerce/src/decode.c#L69 to something like char input[4] = ""; but I have absolutely no idea if that could have any potential side effects.

The questions I have are:

• How in sync are we keeping this repo with the origin?
• Is there another way to do this via the Makefile?

/cc @rayward @chrisboulton

[dsolsona]

🤔 the tests are failing, but it doesn't seem to be related to my changes, as they also fail on master #4

[dsolsona]

I figured out how to add this to the Makefile, which is probably the right place for this. Check the last commit 688440f

[dsolsona]

Actually, it seems the author had a patch for this that never got merged p0pr0ck5@96b0a04. Should I apply this commit in this PR or we just keep the no warning?

[cwalsh]

Probably better to pull in that patch though.

[dsolsona]

@cwalsh I've pushed the changes with the patch