diff options
| author | Derek Buitenhuis <derek.buitenhuis@gmail.com> | 2013-01-06 13:25:07 -0500 |
|---|---|---|
| committer | Derek Buitenhuis <derek.buitenhuis@gmail.com> | 2013-01-07 14:55:49 -0500 |
| commit | ac2603be28602bea76cf38bdbf37aead0dc2979a (patch) | |
| tree | d6912e4f1346fb826e81c7a25f6b09b9883f7f1e /doc | |
| parent | dc3e12d1cb65d74fb120197ce869a205718b6715 (diff) | |
| download | ffmpeg-ac2603be28602bea76cf38bdbf37aead0dc2979a.tar.gz | |
doc: Mention memory allocation in the fuzz testing section
It's obviously undesireable to blindly allocate memory based on
a damaged 'size' value, for example.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/developer.texi | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/doc/developer.texi b/doc/developer.texi index c10d44a2c0..691a907949 100644 --- a/doc/developer.texi +++ b/doc/developer.texi @@ -453,7 +453,8 @@ send a reminder by email. Your patch should eventually be dealt with. Did you test your decoder or demuxer against damaged data? If no, see tools/trasher, the noise bitstream filter, and @uref{http://caca.zoy.org/wiki/zzuf, zzuf}. Your decoder or demuxer - should not crash or end in a (near) infinite loop when fed damaged data. + should not crash, end in a (near) infinite loop, or allocate ridiculous + amounts of memory when fed damaged data. @item Does the patch not mix functional and cosmetic changes? @item |