Compilation warnings with gcc 8.3.0

[dur-randir]

The following warnings are generated when building this module with gcc 8.3.0 on Debian:

In file included from Encode.xs:9:
Encode.c: In function ‘XS_Encode_decode’:
../../XSUB.h:185:20: warning: unused variable ‘ix’ [-Wunused-variable]
#define dXSI32 I32 ix = XSANY.any_i32
^~
../../XSUB.h:185:20: note: in definition of macro ‘dXSI32’
#define dXSI32 I32 ix = XSANY.any_i32
^~
Encode.c: In function ‘XS_Encode_encode’:
../../XSUB.h:185:20: warning: unused variable ‘ix’ [-Wunused-variable]
#define dXSI32 I32 ix = XSANY.any_i32
^~
../../XSUB.h:185:20: note: in definition of macro ‘dXSI32’
#define dXSI32 I32 ix = XSANY.any_i32

[pali]

Duplicate of #140
So I think this issue can be closed.

[dankogai]

Closing as @pali suggests.

[dur-randir]

There's a sane way to silence such warnings, by adding PERL_UNUSED_ARG(ix) into the function's body. Why do you think it's impossible to do?

[pali]

Look, you reported problem marked to autogenerated file Encode.c. There is no variable ix declared in Encode.xs. So problem is in generator - xsubpp. Please report this bug to that program. It is not in p5-encode. You cannot add some random macros on random places which access variables which are not declared at all.

[dur-randir]

xsubpp can't magically know that the functionality you've asked from it (by specifying 'bytes2str = 0') will be unused (by not making any difference between 'decode' and 'bytes2str') - as you ask it to parse C language, which it doesn't. So it seems fair to report this bug to you. If you had indeed differentiated the alias 'bytes2str' for some custom code, you'd have to use 'ix', so your phrase 'access variables which are not declared at all' is not quite right.

[pali]

If special warnings are enabled by compiler (gcc is not the only one used for compiling perl, there is e.g. used also hpcc) then xsubpp should generate code with marks that some autogenerated variables does not have to be used and that compiler should not generate warning for it.

From Encode.xs code point of view, there is nothing wrong. Problem is that gcc generate warning for autogenerated code by xsubpp. So these two external parts needs to be configured in way that they understand each other correctly.

Basically I do not see any reason why currently written code is bad or wrong. Or if there is missing something to it or that code is suspicious. If yes, please point out where where it is and why.
And so I do not see reason why adding such hack into clean and correct code.

For code which comes from Encode.xs or is generated from Encode.xs, xsubpp put #file and #line marks so compiler (gcc) reports warnings/errors back to that original file Encode.xs (even it is compiling Encode.c).

So in my opinion this problem should be reported to xsubpp that for gcc compiler it should add marks for autogenerated variables that they could be unused.