[Ffmpeg-cvslog] r5740 - in trunk/libavutil: Makefile lls.c lls.h

[Rich Felker]

On Fri, Jul 14, 2006 at 10:49:19PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Jul 14, 2006 at 09:35:01PM +0100, M?ns Rullg?rd wrote:
> > Michael Niedermayer <michaelni at gmx.at> writes:
> > 
> > > i agree but theres a problem, some asserts are irrelevant
> > > speedwise and some are in speed-critical parts, and there are some people
> > > (me for example, and possibly other developers...) who want the rarely
> > > executed asserts() to be enabled while the often executed ones should be
> > > disabled in their build ... a global NDEBUG is not enough here
> > >
> > > IIRC ive already at least suggested once that 2 av_asserts, one for
> > > speedcritical and one for non-speedcritical parts should be added
> > > yeah i shouldnt suggest but rather do the work myself i know ...
> > 
> > We could also use a single av_assert with a numerical argument
> > specifying the debug level at which to enable it.
> > 
> > Something like
> > 
> > #ifndef AV_DEBUG
> > #define AV_DEBUG 0
> > #endif
> > 
> > #define av_assert(level, expr) do { \
> >     if(level < AV_DEBUG){           \
> >         assert(expr)                \
> >     }                               \
> > } while(0)
> 
> no objections, feel free to commit
> 
> 
> about the levels, id suggest:
> 0   assert failure could lead to exploits
> 1   assert in speed uncritical code
> 2   assert in speed critical code

Regarding level 0, if this is the case the code needs to be fixed,
since aborting the calling app on bad input is hardly acceptable
either... I tend to think there's no reason to have a special assert
level for it. If finding the bug and adding the assert isn't too hard,
adding the "return failure" or "longjmp out" code shouldn't be much
harder and prevents "DoS" vulns which could also be nasty when lavc is
used inside some sort of long-lived/server process.

Rich