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

[Måns Rullgård]

Baptiste Coudurier <baptiste.coudurier at gmail.com> writes:

> On 06/30/2010 01:54 PM, Reimar D?ffinger wrote:
>> On Wed, Jun 30, 2010 at 01:42:56PM -0700, Baptiste Coudurier wrote:
>>> Will see if any compiler decide to fail in the future.
>>> For now, none decided to fail.
>>
>> Failing at runtime is hardly better.
>
> I'm not saying it is.
>
>>> I'm against adding that flag, and until the majority of developpers
>>> approves, it won't be added.
>>
>> Do we really have to vote on that?  And if we do, how about a few
>> arguments, you haven't said _why_ you are against while I think we
>> have mentioned a few rather good reasons to?  And either call or
>> stop this flaming (everyone), it's really ridiculous today.
>
> Well, first, I don't see a need to be more strict than the compiler,
> if the latter doesn't even warn about it.

There is, unfortunately, old code out there relying on lax function
declarations, and the C standard says it is allowed but has undefined
behaviour in many cases.  It would thus be wrong of a compiler to
produce an error by default for such code.

If the compiler has a feature to disallow a construct we agree should
never be used, using this will help us avoid accidentally doing
dangerous things.  That's why we have warnings in the first place.

> Also a few functions do not use all the parameters, when using func
> pointers, it will cause warnings (unused arguments), with unspecified
> prototype, it won't. But that's more an explanation of why there isn't
> any prototype for the read() function.

Unused function arguments do not give a warning in FFmpeg.  If that
warning ever becomes default in gcc, I will take care of disabling it.

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