[FFmpeg-devel] [PATCH] mxfdec: make it work with other calling conventions

Baptiste Coudurier baptiste.coudurier
Wed Jun 30 22:42:56 CEST 2010

On 06/30/2010 01:34 PM, M?ns Rullg?rd wrote:
> Baptiste Coudurier<baptiste.coudurier at gmail.com>  writes:
>>> I will make prototype-less functions an error.
>> You will do no such thing without majority approval. You do not make
>> the rules here, is that clear ?
> Quoting the developer documentation, Coding Rules section:
> ---cut---
> FFmpeg is programmed in the ISO C90 language with a few additional
> features from ISO C99, namely:
> @itemize @bullet
> @item
> the @samp{inline} keyword;
> @item
> @samp{//} comments;
> @item
> designated struct initializers (@samp{struct s x = @{ .i = 17 @};})
> @item
> compound literals (@samp{x = (struct s) @{ 17, 23 @};})
> @end itemize
> ---cut---
> I don't see any exception there for omitting function prototypes.
> Furthermore, the C standard says this:
> ---cut---
> The declarator in a function definition specifies the name of the
> function being defined and the identifiers of its parameters. If the
> declarator includes a parameter type list, the list also specifies the
> types of all the parameters; such a declarator also serves as a
> function prototype for later calls to the same function in the same
> translation unit. If the declarator includes an identifier list,
> the types of the parameters shall be declared in a following
> declaration list. In either case, the type of each parameter is
> adjusted as described in for a parameter type list; the
> resulting type shall be an object type.
> If a function that accepts a variable number of arguments is defined
> without a parameter type list that ends with the ellipsis notation,
> the behavior is undefined.
> ---cut---
> As we can see, the type of every parameter must be specified, and
> calling a function with the wrong arguments causes undefined
> behaviour.
> Making this a hard error is in perfect agreement with established rules.

Will see if any compiler decide to fail in the future.
For now, none decided to fail.

I'm against adding that flag, and until the majority of developpers 
approves, it won't be added.

Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org

More information about the ffmpeg-devel mailing list