[FFmpeg-devel] [PATCH] do not #include assert.h directly

Michael Niedermayer michaelni
Wed May 14 03:00:31 CEST 2008


On Tue, May 13, 2008 at 11:49:18PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Tue, May 13, 2008 at 07:47:56PM +0100, Mans Rullgard wrote:
> >> libavutil/internal.h includes assert.h, defining NDEBUG if DEBUG is
> >> not defined.  Including assert.h again has no effect, and is possibly
> >> confusing.
> >
> > IMHO internal.h should not #include assert.h
> 
> I figured it might be a good idea to have the same assert() behaviour
> (enabled/disabled) everywhere.  Either way, it should be consistent.

Well, the asserts fall in several different categories.
1. Ones in speed critical code
2. Ones related to security
3. Remainder

1. should generally be disabled unless one needs them for debuging
2. should generally be enabled unless one knows what he is doing
   (i think we do prefer redundant checks over exploits ...)
3. should probably be enabled unless CONFIG_SMALL is defined

Because of the possibility of asserts() falling in category 2. I do not
feel well with throwing the cases out which unconditionally enabled
asserts. At least not without some reviewing of all affected asserts but
i do not volunteer for that.

Besides above i agree that asserts should be handled consistently.

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

Thouse who are best at talking, realize last or never when they are wrong.
-------------- 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-devel/attachments/20080514/fea6b9db/attachment.pgp>



More information about the ffmpeg-devel mailing list