On Sun, Nov 29, 2015 at 1:00 PM, wm4 <nfx...@googlemail.com> wrote:
> On Wed, 25 Nov 2015 10:35:31 -0500
> Alex Agranovsky <a...@sighthound.com> wrote:
>
>> From 70a6e1b0f3d47698bf49c3c766d5472646bff71a Mon Sep 17 00:00:00 2001
>> From: Alex Agranovsky <a...@sighthound.com>
>> Date: Tue, 24 Nov 2015 00:06:14 -0500
>> Subject: [PATCH 1/2] Allow mpjpeg demuxer to process MIME parts which do not
>>  include Content-Length header.
>
> Commit messages should start with a prefix (like "avformat/mpjpeg: "),
> and then maybe up to 60 characters of summary. If more text is needed,
> it should be part of the commit body (i.e. the part after the subject
> line).
>
> (Same for the second patch.)
>
>>
>> Fixes ticket 5023
>>
>> Signed-off-by: Alex Agranovsky <a...@sighthound.com>
>> ---
>>  libavformat/mpjpegdec.c | 164 
>> +++++++++++++++++++++++++++++++++++++-----------
>>  1 file changed, 126 insertions(+), 38 deletions(-)
>>
>> diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c
>> index 2749a48..b9093ea 100644
>> --- a/libavformat/mpjpegdec.c
>> +++ b/libavformat/mpjpegdec.c
>> @@ -23,22 +23,15 @@
>>
>>  #include "avformat.h"
>>  #include "internal.h"
>> +#include "avio_internal.h"
>>
>> -static int get_line(AVIOContext *pb, char *line, int line_size)
>> -{
>> -    int i = ff_get_line(pb, line, line_size);
>>
>> -    if (i > 1 && line[i - 2] == '\r')
>> -        line[i - 2] = '\0';
>> -
>> -    if (pb->error)
>> -        return pb->error;
>> -
>> -    if (pb->eof_reached)
>> -        return AVERROR_EOF;
>>
>> -    return 0;
>> -}
>> +typedef struct MPJPEGDemuxContext {
>> +    char*       boundary;
>> +    char*       searchstr;
>> +    int         searchstr_len;
>> +} MPJPEGDemuxContext;
>>
>>
>>  static void trim_right(char* p)
>> @@ -47,12 +40,28 @@ static void trim_right(char* p)
>>      if (!p || !*p)
>>          return;
>>      end = p + strlen(p) - 1;
>> -    while (end != p && av_isspace(*end)) {
>> +    while (end >= p && av_isspace(*end)) {
>
> I still think that this change is theoretically unclean and invalid,
> because end will point before the memory location at one point. Maybe
> someone else can give a second opinion whether it's invalid or allowed
> by the C standard, and whether it's ok to ignore it. (Besides writing a
> valid trim shouldn't be hard.)

Don't know what you are referring to here, but dereferencing is
clearly invalid. However, in order to allow common loop idioms,
pointer arithmetic one element beyond a array (memory) range is valid:
https://stackoverflow.com/questions/8133804/negative-array-index-in-c.

[...]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to