[FFmpeg-user] 'ff_h264_handle_aggregated_packet' does not match original declaration

[Reindl Harald]

Am 12.02.2017 um 14:52 schrieb Carl Eugen Hoyos:
> 2017-02-12 5:36 GMT+01:00 Reindl Harald <h.reindl at thelounge.net>:
>>
>> Am 12.02.2017 um 03:30 schrieb Carl Eugen Hoyos:
>>>
>>> 2017-02-12 3:23 GMT+01:00 Reindl Harald <h.reindl at thelounge.net>:
>>>
>>>> gcc-6.3.1-1.fc24.x86_64
>>>
>>> gcc.gnu.org doesn't know this release;-)
>>>
>>> Anyway: Please understand that several hundred real, user-reported,
>>> reproducible bugs exist in current FFmpeg, some of them regressions.
>>> I hope you agree that compiler bugs are not our priority...
>>> (It's bad enough that we have to invest time in "undefined behaviour"
>>> where no compiler ever failed.)
>>
>> no i do *not* agree beause some some of that warnings may the
>> reason for unfixed bugs
>
> I wonder what "may" means here...

google for the word

you don't know the underlying reason of reported but unfixed bugs andf 
much more not the reason for existing and currently not reported bugs 
and when of the reasons could be some code smell

>> things like "src/libavcodec/mpegvideo.c:960:17: warning: this
>> 'if' clause does not guard... [-Wmisleading-indentation]" are a clear
>> indication that this code should be reviewed
>
> Please do;-)

maybe you still don't realize that i am not a C/C++ developer and have 
no plans to change that but if i woul dbe one no single line of code 
would be commited by me where a recent compiler works and before i 
consider implement new features i would cleanup my stuff like the last 
decade any PHP code from me was running with "error_reporting E_ALL | 
E_STRICT" in production

>> and to be frankly where i develop software (though not in C/C++ but that
>> don't matter) i first keep my house clean and fix any warnings software can
>
> Sounds as if we found a new contributor - welcome!

what exactly did you not undestandin "though not in C/C++"

>> detected automatically and *then* consider to waste my time trying to
>> reprodce things which could have been gone by get rid of all the code smell
>
> It's funny that you wrote this mail a few hours after I fixed most
> of the current warnings - or "several" if you prefer

it's funny that your first reply sounded like "don't care because could 
not reprocude it within 10 seconds"

> (Yes, we do exactly what you ask for, I just request that you realize
> fixing these warnings practically never fixes a real issue, while we
> know about many - ! - real issues including remote DOS, regressions
> on valid input files and sometimes subtle change of behaviour, both
> intended and unintended.)
>
>>> That's apart from the fact that --extra-cflags and --extra-ldflags
>>> generally make bug reports invalid (as you correctly indicated)
>>> except for paths and libraries
>>
>> you still refused to answer my question if you did a LTO build as you
>
> (You refused to answer my question.)

where was the question in your inital repsonse?

>> pretended you can't reporduce it, as you always request full input
>> of ffmpeg command lines why don't you do the same?
>
> I was hoping my original comment made it crystal-clear that I did
> try to reproduce the issues you saw.

no, it soundd just like "i spent 10 seconds, the things did not jup 
straigth into my face and since we have so many other work i don't waste 
any time for cleanups"

>> src/libavformat/rtpdec_formats.h:41:5: warning: type of
>> 'ff_h264_handle_aggregated_packet' does not match original declaration
>> [-Wlto-type-mismatch]
>>  int ff_h264_handle_aggregated_packet(AVFormatContext *ctx, PayloadContext
>> *data, AVPacket *pkt,
>>      ^
>> src/libavformat/rtpdec_h264.c:206:5: note:
>> 'ff_h264_handle_aggregated_packet' was previously declared here
>>  int ff_h264_handle_aggregated_packet(AVFormatContext *ctx, PayloadContext
>> *data, AVPacket *pkt,
>>      ^
>> src/libavformat/rtpdec_h264.c:206:5: note: code may be misoptimized unless
>> -fno-strict-aliasing is used
>
> So what is your initial analysis of this warning?
> (You can find mine above, the line starts with "I hope".)

that there is a sloppy type/pointer handling