[Ffmpeg-cvslog] CVS: ffmpeg/libavformat rtp.c,1.24,1.25

[Rich Felker]

On Sat, Apr 01, 2006 at 11:49:34AM +0300, Ivan Kalvachev wrote:
> 2006/4/1, Rich Felker <dalias at aerifal.cx>:
> > On Sat, Apr 01, 2006 at 12:34:51AM +0100, M?ns Rullg?rd wrote:
> > > Luca Barbato <lu_zero at gentoo.org> writes:
> > >
> > > > Richard Felker CVS wrote:
> > > >> Update of /cvsroot/ffmpeg/ffmpeg/libavformat
> > > >> In directory mail:/var2/tmp/cvs-serv5251
> > > >> Modified Files:
> > > >>    rtp.c Log Message:
> > > >> fix constraint violation: libavformat is not allowed to modify state of caller, including rng state
> > > >> Index: rtp.c
> > > >> ===================================================================
> > > >> RCS file: /cvsroot/ffmpeg/ffmpeg/libavformat/rtp.c,v
> > > >> retrieving revision 1.24
> > > >> retrieving revision 1.25
> > > >> diff -u -d -r1.24 -r1.25
> > > >> --- rtp.c  1 Mar 2006 22:45:27 -0000       1.24
> > > >> +++ rtp.c  30 Mar 2006 16:44:32 -0000      1.25
> > > >> @@ -532,9 +532,9 @@
> > > >>          payload_type = RTP_PT_PRIVATE; /* private payload type */
> > > >>      s->payload_type = payload_type;
> > > >>  -    s->base_timestamp = random();
> > > >> +    s->base_timestamp = 0; /* FIXME: was random(), what should this be? */
> > > >
> > > > random (check the rfc)
> > > >
> > > >>      s->timestamp = s->base_timestamp;
> > > >> -    s->ssrc = random();
> > > >> +    s->ssrc = 0; /* FIXME: was random(), what should this be? */
> > > >
> > > > any value would fit, random warmly suggested
> > >
> > > What sort of sick spec mandates random values?  It's not like we're
> > > generating encryption keys here.
> >
> > 0 is a random number, and so is any arbitrarily long string of zeros.
> > It may be low probability, but if the protocol can't handle it then
> > the protocol is broken.
> >
> > If someone wants to implement their own PRNG with internal (constant!)
> > seed or seed provided by the called, be my guest. However, keep in
> > mind the following are all illegal:
> >
> > - corrupting the calling program's state (the caller may be using
> >   random and the internal state it keeps and expect deterministic
> >   results given the same seed!)
> > - use of non-reentrant library functions, since lavf muxers/demuxers
> >   may be used in multithreaded programs (random is non-reentrant).
> > - anything that leaks information, especially the time() function.
> 
> 
> Hum... how this patch changes anything?
> 
> The caller state is still changed. So it doesn't do whay is says it does.

Huh?! Which patch?
My commit removed all calls to random. Does evaluating "0" change the
caller's state??

Rich