summaryrefslogtreecommitdiffstats
path: root/courgette/image_info_unittest.cc
diff options
context:
space:
mode:
authorcevans@chromium.org <cevans@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-09-03 18:27:40 +0000
committercevans@chromium.org <cevans@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-09-03 18:27:40 +0000
commitc87a1361b7f037393beaf6015efe4baa672a2a35 (patch)
treed1ac97e956eaced38673961a82104ab1dc42e115 /courgette/image_info_unittest.cc
parent48f0ce4e0243f8a5f293c6dfeccf9ef4c28f0dc7 (diff)
downloadchromium_src-c87a1361b7f037393beaf6015efe4baa672a2a35.zip
chromium_src-c87a1361b7f037393beaf6015efe4baa672a2a35.tar.gz
chromium_src-c87a1361b7f037393beaf6015efe4baa672a2a35.tar.bz2
Do not permit a seek to a negative position. This was already an error
condition (in the FFmpeg glue code) but the position would be left set to negative. If the API consumer ignored the error code for the seek and then attempted a read, that might be a bad state. I am fixing this to avoid any risk of this upsetting the stream read code. FFmpeg would seem to commit this sort of API abuse. BUG=NONE TEST=FFmpegDemuxerTest.ProtocolGetSetPosition Review URL: http://codereview.chromium.org/201002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25334 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'courgette/image_info_unittest.cc')
0 files changed, 0 insertions, 0 deletions