#3179 Parameter type mismatches in PIC16 backend code

[Benedikt Freisen]

Some tinkering with the compilation/linking process exposed some function parameter type mismatches in the PIC16 backend code.

The most worrying ones are these declarations in pcodepeep.c

pCodeOp *pic16_popCopyGPR2Bit(pCodeOpReg *pc, int bitval);
pCodeOp *pic16_popCombine2(pCodeOp *, pCodeOp *, int);
char *pic16_pCode2str(char *str, int size, pCode *pc);

combined with the definitions

pCodeOp *pic16_popCopyGPR2Bit(pCodeOp *pc, int bitval);
pCodeOp *pic16_popCombine2(pCodeOpReg *src, pCodeOpReg *dst, int noalloc);
char *pic16_pCode2str(char *str, size_t size, pCode *pc);

in pcode.c, gen.c and again pcode.c, respectively.

Can that even work, or will funny things happen when these code paths are reached?

(This was found in revision [r12056], but is probably ancient.)

[Benedikt Freisen]

This appears to be a case of code that shouldn't work but still does.
There's a parameter type mismatch between declaration and definition, but because the first element of a pCodeOpReg is a pCodeOp and because int and size_t can share the same width, it winds up functioning just fine.
*barf*

[Philipp Klaus Krause]

I have no idea how much of the pci16 port works. But apparently the port has users, so something must be working somehow.
Still this issue looks like something that needs fixing.

[Benedikt Freisen]

Two out of three are fixed in [r13749]. The third, pic16_popCombine2, relies on type punning, anyway.
Sensible testing was not possible, but the risk of making code like the above worse is minuscule.