[FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: remove unused function
lq at chinaffmpeg.org
Fri Jun 28 02:06:41 EEST 2019
> 在 2019年6月28日，04:25，Reimar Döffinger <Reimar.Doeffinger at gmx.de> 写道：
> On 27.06.2019, at 17:35, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:
>> On Thu, Jun 27, 2019 at 9:44 AM Nicolas George <george at nsup.org> wrote:
>>> Kieran Kunhya (12019-06-27):
>>>> I'm happy to do it now that I am aware of the issue. I will do it when I
>>>> at home in a few days.
>>> Thanks. I am sure Steven will not mind waiting a few days.
>>>> This absolutism is absurd.
>>> Do you have an example of situation where dead code is good?
>> If i could add my 2 cents, for a reverse engineered codec it's important to
>> leave unused functions purely for documentation purposes, so that future
>> maintainers could implement and read about it right away, rather than
>> digging in a large and messy git history.
>> Additionally most compilers run passes that drop dead code already in a way
>> that does not affect runtime one bit. So I really don't see any gains in
>> removing these 14 lines of code.
> I'd note that intentionally dead code should at least have a comment, and
> maybe even a #if 0
Yes, i think if the maintainers want use the unused code shortly time, maybe #if 0 is better way to fix the compiling waring.
Because that is means the code is not in use now, perhaps it will be used In the future, so should add comment for that.
not just stay it here, compiler give me warning, that is true, it’s dirty when compiling the project.
If there have much more warning when compiling, i think no people like full screen warning message.
perhaps there will have second, three, four, and so on if ignore the first one with this kind of message.
Make the code clean, At the very least, no warning when compiling.
> would make sense (though has the disadvantage of not
> even compile-testing the code).
> In case of an actual bug like here I would say dead code if nothing else is a reminder of the
> bug, though admittedly a very poor one.1
> Either way I suggest to discuss such things more relaxed, a few days more or
> less hardly matters and there might be useful insights from other people (of
> course I don't mean to delay non-controversial stuff nobody has any comments/objections on).
> Best regards,
> Reimar Döffinger
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-devel