[FFmpeg-devel] [PATCH] mxfdec: make it work with other calling conventions
Wed Jun 30 23:19:26 CEST 2010
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.
mans at mansr.com
More information about the ffmpeg-devel