I haven't pushed it upstream to Klaus, I think the preferable solution is to do it as a plugin - search for the eepg plugin which incorporates the parsing code.
OK, thanks. Fedora 15 is still using VDR 1.6.x but the plugin looks small enough that I'm hoping it will work anyway :-).
BTW, I see that eepg.c is using sscanf() with GNU-specific "%a[range]" tokens. Wouldn't it be more practical to use "%m[range]" tokens instead, c.f. the man page for sscanf from glibc:
Since version 2.7, glibc also provides the m modifier for the same pur‐ pose as the a modifier. The m modifier has the following advantages:
* It may also be applied to %c conversion specifiers (e.g., %3mc).
* It avoids ambiguity with respect to the %a floating-point conversion specifier (and is unaffected by gcc -std=c99 etc.)
* It is specified in the upcoming revision of the POSIX.1 standard.
Cheers, Chris
On 12.08.2011 00:59, Chris Rankin wrote:
I haven't pushed it upstream to Klaus, I think the preferable solution is to do it as a plugin - search for the eepg plugin which incorporates the parsing code.
OK, thanks. Fedora 15 is still using VDR 1.6.x but the plugin looks small enough that I'm hoping it will work anyway :-).
BTW, I see that eepg.c is using sscanf() with GNU-specific "%a[range]" tokens. Wouldn't it be more practical to use "%m[range]" tokens instead, c.f. the man page for sscanf from glibc:
Since version 2.7, glibc also provides the m modifier for the same pur‐ pose as the a modifier. The m modifier has the following advantages: * It may also be applied to %c conversion specifiers (e.g., %3mc). * It avoids ambiguity with respect to the %a floating-point conversion specifier (and is unaffected by gcc -std=c99 etc.) * It is specified in the upcoming revision of the POSIX.1 standard.
Would this also cure the problem mentioned in VDR's timers.c:
//XXX Apparently sscanf() doesn't work correctly if the last %a argument //XXX results in an empty string (this first occured when the EIT gathering //XXX was put into a separate thread - don't know why this happens... //XXX As a cure we copy the original string and add a blank. //XXX If anybody can shed some light on why sscanf() failes here, I'd love //XXX to hear about that!
If so, would you care to provide a (tested) patch that replaces all occurrences of %a in sscanf() calls with %m?
Klaus