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

Måns Rullgård mans
Thu Jul 17 20:41:30 CEST 2008

Erik Hovland <erik at hovland.org> writes:

> On Thu, Jul 17, 2008 at 05:57:04PM +0100, M?ns Rullg?rd wrote:
>> Erik Hovland wrote:
>> > The goto in ff_h264_find_frame_end() is inside an else clause. The
>> > initialization for v happens in the if clause elsewhere. That means that
>> > it is possible for the goto to fire without the initialization of v
>> > happening. Normally this isn't a problem. But gcc recognizes this and
>> > throws an internal parse warning. It then has to go through a special
>> > code branch to take care of this. If the initialization of v always
>> > happens before either clause this does not happen. The attached patch
>> > does just that.
>> The gcc internals are irrelevant.  Only two things matter: 1) whether
>> it is valid C code, and 2) whether gcc issues a warning.  As far as
>> I can tell, it is valid C.  The question is thus, does it trigger a
>> warning with gcc?
> It triggers a warning with gcc that the user never sees.

In that case there is no warning.

> I do agree. It is valid C. But it is playing a bit loose with its
> validity.

Code is either valid or not.  There are no states in between.  This
code clearly falls in the valid category.

> A static analysis tool can see the warning because it can see what gcc
> emits.

You mean a gcc-based static analysis tool, which is something I
wouldn't put a lot of faith in.

> There are a few parse warnings that are valid C, but are a bit
> iffy. This happens to be one of them. Parameter hiding is another
> example.

No matter what language is used, there will always be constructs
which, while syntactically valid and semantically well-defined, are
more error-prone than others.  Exactly which ones warrant a warning
will always be a matter of personal preference.

> But hey, the reason I post these patches is to get this kind of
> feedback.

Perhaps you could have been clearer about this.  From your mail, it
was impossible to tell whether there was an actual bug, a compiler
warning (the kind that gets printed), or something else.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list