[FFmpeg-devel] [PATCH] make sure initialization happens even after goto fires

Måns Rullgård mans
Thu Jul 17 21:14:14 CEST 2008


Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:

> Hello,
> On Thu, Jul 17, 2008 at 07:55:57PM +0100, M?ns Rullg?rd wrote:
>> > --- libavcodec/h264_parser.c	(revision 14263)
>> > +++ libavcodec/h264_parser.c	(working copy)
>> > @@ -59,10 +59,7 @@
>> >              if(v==7 || v==8 || v==9){
>> >                  if(pc->frame_start_found){
>> >                      i++;
>> > -found:
>> > -                    pc->state=7;
>> > -                    pc->frame_start_found= 0;
>> > -                    return i-(state&5);
>> > +                    goto found;
>> >                  }
>> >              }else if(v==1 || v==2 || v==5){
>> >                  if(pc->frame_start_found){
>> > @@ -80,6 +77,11 @@
>> >      }
>> >      pc->state= state;
>> >      return END_NOT_FOUND;
>> > +
>> > +found:
>> > +    pc->state=7;
>> > +    pc->frame_start_found= 0;
>> > +    return i-(state&5);
>> >  }
>> 
>> The question is, is this as fast?  I agree it's nicer structurally.
>
> Since gcc 4.3.1 generates exactly the same code, for this case the
> answer is a clear yes.

Yes, with that compiler.

> Actually I would find the current code to be more likely for the
> compiler to mess up and do something stupid like doing the stack
> allocation for v upon the second goto (though with that statement I
> probably only show my ignorance about writing compilers ;-) ).

Compilers usually allocate the maximum required stack space all at
once on entry to the function, and release it all on return, the
exceptions naturally being variable-sized arrays and alloca() calls.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list