[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