[Ffmpeg-devel] time for a release?
Tue Jan 31 21:30:39 CET 2006
Michael Niedermayer wrote:
>> About those, Micheal Niedermayer said:
>> "rejected, these silly signed/unsigned casts make the code less readable
>> feel free to send a patch which disables/filters these warnings or
>> change the actual types where its correct and possible"
>> I have no other solution for the issue, considering it is a buffer used
>> as a raw unsigned byte buffer some places and as a char buffer in others
>> (depending on if ffserver is writting to http header or body).
>> Splitting the buffer into two buffers (one uint8_t, one char) would be
>> pointless, changing the type to one or the other would still give
>> warnings, and using something to disable the warnings is just a bad
>> idea. Consider this patch dead unless someone has a better idea.
> why is disabling the warning a bad idea?
> could you provide a single case where it pointed to buggy code in a real
> existing project? and iam just talking about the f((signed)b) style stuff
> not mixing signedness in comparissions or so
> and maybe "rejected" was a bit too strong, if someone of the ffmpeg devels
> seriously wants the patch applied i wont object ...
No worries about the rejected word, I understand that ffmpeg gets a
ton of patches from every-which-where and there's not enough hours in
the day to write out page-long dissertations on why things may or may
not be included (especially with such a trivial change such as this).
You're right though, I can think of not a single case where there
was a real error created by assigning pointer of different signedness to
each other. I will ignore them.
That leaves 2 other warnings, one about IPAddressACL not being
uninitialized (which it might be if there are errors in the conf file,
but we're planning to bomb out anyway so what's the point?). The other
is about get_longterm_datarate being unused, which has been true for
over a year now. I'm not sure what the original intent of this function
was (maybe had something to do with pre-preroll code?).
Anyway, they're all benign so no need to do anything about them I
More information about the ffmpeg-devel