On 08.02.2014 14:34, Tony Houghton wrote:
On Sat, 08 Feb 2014 13:51:10 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
channels.c:45:119: warning: data argument not used by format string [-Wformat-extra-args] snprintf(buffer, sizeof(buffer), rid ? "%s-%d-%d-%d-%d" : "%s-%d-%d-%d", *cSource::ToString(source), nid, tid, sid, rid); ~~~~~~~~~~~~~ ^This is explicitly checked with 'rid ? ...', so the warning is unjustified (although the compiler probably has a hard time figuring that out ;-).
The warning is justified, because if rid is 0 it's still there as an argument, but just happens to have a value of 0. I think you can make snprintf "consume" it without printing anything by adding %.d to the second format string.
I'm afraid not. If I run
#include <stdio.h> int main(void) { for (int n = 0; n < 2; n++) printf(n ? "'%d-%d'\n" : "'%d%.d'\n", 1, 2); return 0; }
I get
'12' '1-2'
But maybe there *is* such a format character, it just isn't "%.d".
eit.c:223:43: warning: comparison of constant 176 with expression of type 'SI::LinkageType' is always false [-Wtautological-constant-out-of-range-compare] if (ld->getLinkageType() == 0xB0) { // Premiere World ~~~~~~~~~~~~~~~~~~~~ ^ ~~~~I assume this is because the enum LinkageType doesn't contain 0xB0. However, the actual value that comes from the SI data may well be 0xB0, so I'm now typecasting uint(ld->getLinkageType()).
If 0xB0 has a significant meaning wouldn't it be a good idea to add it to the enum?
You're probably right. Since there are already several "Premiere" related definitions in libsi/si.h I guess it won't hurt to add yet another one. <rant>The DVB standard should never have allowed all this "private" stuff...</rant>
receiver.c:28:6: warning: indirection of non-volatile null pointer will be deleted, not trap [-Wnull-dereference] *(char *)0 = 0; // cause a segfault ^~~~~~~~~~ receiver.c:28:6: note: consider using __builtin_trap() or qualifying pointer with 'volatile'Can you suggest a different way of causing a segfault at this point?
You could add volatile as the warning suggests. Is there a good reason not to use abort() instead?
The idea behind this was to allow for easy backtracking in such a case. I believe abort() wouldn't allow this, would it?
Klaus