Re: Potential divison-by-zero in outqueue.cpp:241

Hi, this issue is a bit tricky. The problem with:

> send.tv_usec = 1000000ul*(rem/rate);

is that it would imply a high error in send.tv_usec; for rem == 89900
and rate == 90000, 89.9 milliseconds would be reduced to 0
microseconds.

if we instead use:

> send.tv_usec = 1000000ul*rem / rate;

for a rem > ~4290, 1000000ul*rem a 32 bits value would overflow.  So
to avoid using 64 bits arithmetics 'send.tv_usec = (1000ul*rem) /
(rate/1000ul);' is used on the assumption that rate is multiple of
1000. This assures that overflow will not occur for rates < 4290000 as
well.

For standard RTP clock rates it holds, but you are right there is the
risk for a division-by-zero. The lowest clock rate I'm used to see is
8khz and the highest 90khz, but if there are applications using lower
bit rates, we could look for a compromise like 'send.tv_usec =
(10000ul*rem) / (rate/100ul);' :) -that would allow rates of up to
429000 and will work for rates multiple of 100.


On Tue, May 24, 2005 at 01:56:57AM +0200, Jonas Schwertfeger wrote:
> Line 241 in outqueue.cpp produces division-by-zero exceptions for RTP 
> clock rates < 1000 because "(rate/1000ul)" evaluates to 0 for rates < 
> 1000. I modified the original line
> 
> send.tv_usec = (1000ul*rem) / (rate/1000ul);
> 
> to
> 
> send.tv_usec = 1000000ul*(rem/rate);
> 
> which fixes the bug. If you ever need clock rates below 1000 you'll have 
> to fix this bug manually until it is fixed by the ccRTP maintainers in a 
> future release.
> 
> Regards
> Jonas
> 
> 
> _______________________________________________
> Ccrtp-devel mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/ccrtp-devel