Hi,
I will ike accentuate the do {}while(0) behavior.
I've seen this in few projects including VDR and at least one plugin
(xineliboutput)
In a code like:
do {
if (condition1)
continue;
} while(condition2);
continue does not translate to a jump to "do", but to a jump to "while"
where the condition2 is evaluated.
do {
if (condition1)
continue;
} while(0);
if equivalent with:
do {
if (condition1)
break;
} while (0);
Regards,
Ilariu
On 2/18/07, Reinhard Nissl <rnissl@xxxxxx> wrote:
>
> Hi,
>
> Dieter Bloms wrote:
>
> > my primary dvb card works fine on both of my Twin-LNB connectors.
> > I can switch the second card via szap and get a video stream via
> > "cat /dev/dvb/adapter1/dvr0 > /tmp/bla" on H and V channels.
> > VDR doesn't get data any data from H channels, but gets data from V
> > channels.
> > I will try to strace vdr and szap to get any difference, maybe they do
> > it in a different way.
>
> I've had a further look into szap's source how it detects the status
> FE_LOCKED. Attached is an updated tuner patch which now also reports
> details for FE_READ_STATUS.
>
> One difference between VDR and szap regarding FE_READ_STATUS is, that
> VDR only honors the read status when ioctl() returns 0 while szap prints
> just an error when ioctl() returns -1.
>
> Furthermore, VDR's handling of errno == EINTR seems to be wrong due to
> the do {} while (0); loop.
>
> BTW: I still assume, that your logfile reports a tuning timeout. If this
> is no longer the case, then you may want to experiment with
> WAIT_FOR_TUNER_LOCK in device.c.
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:rnissl@xxxxxx
>
> _______________________________________________
> vdr mailing list
> vdr@xxxxxxxxxxx
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/vdr/attachments/20070218/b054395e/attachment.htm
