[FFmpeg-cvslog] r16746 - trunk/libavcodec/rectangle.h

Michael Niedermayer michaelni
Sun Jan 25 04:01:57 CET 2009


On Sat, Jan 24, 2009 at 03:30:36PM +0000, M?ns Rullg?rd wrote:
> Diego Biurrun <diego at biurrun.de> writes:
> 
> > On Sat, Jan 24, 2009 at 02:51:22PM +0000, M?ns Rullg?rd wrote:
> >> diego <subversion at mplayerhq.hu> writes:
> >> 
> >> > Log:
> >> > Add required headers to fix 'make checkheaders'.
> >> >
> >> > --- trunk/libavcodec/rectangle.h	Sat Jan 24 15:32:22 2009	(r16745)
> >> > +++ trunk/libavcodec/rectangle.h	Sat Jan 24 15:46:00 2009	(r16746)
> >> > @@ -28,7 +28,10 @@
> >> >  #ifndef AVCODEC_RECTANGLE_H
> >> >  #define AVCODEC_RECTANGLE_H
> >> >
> >> > +#include <assert.h>
> >> 
> >> Be careful with adding assert.h.  You just enabled assert() checking
> >> unconditionally in that file and anything that includes it.  Before
> >> this commit, assert.h was included through internal.h, which sets
> >> NDEBUG before including it.
> >
> > What is the proper solution then?  Adding #define NDEBUG or #including
> > internal.h instead?
> 
> I don't know.  Michael refused to talk about it last time I brought it
> up.

huh?
i suggested a solution and was entirely ignored by everyone

The problem being that there are different types of asserts, some
* being in speed critical code, these we dont want enabled unless realy needed
* being about security related checks like (we know it fits in the buffer but
  lets put an assert there anyway ...)
* being neither of above

if these 3 are split, we can handle things globally instead of per file.
But currently
Enabling everything globally means a huge speedloss and is unacceptable
Disabling everything globally means debuging will be harder as users have
them disabled and it might lead to secholes as well as missing bugs
because the asserts that would give hints where disabled.

Ive not reviewed diegos commits (yet) but no asserts should be changed
between enable<->disable, they are enabled on a per file base currently
and this is the best we can do until someone does the split suggested
above, at least as far as i can see ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20090125/31deadf4/attachment.pgp>



More information about the ffmpeg-cvslog mailing list