[FFmpeg-cvslog] r11690 - trunk/libavcodec/h263.c
Thu Jan 31 21:05:32 CET 2008
On Thu, Jan 31, 2008 at 06:52:20PM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> > On Wed, Jan 30, 2008 at 09:32:35PM -0800, Mike Melanson wrote:
> >> Rich Felker wrote:
> >> >> Maybe thread-local storage? :)
> >> >
> >> > Umm, the whole point was about valid C. There is no such thing in the
> >> > C language and even if there were, its performance is MUCH worse than
> >> > normal variables. Also it does not solve the reentrancy problem; for
> >> > example, using a decoder from a signal handler would not be safe.
> >> Yeah, I know. I just wanted to see your head explode. :) I hope there's
> >> some reasonable solution for making this warning go away so we can raise
> >> the S/N ratio on our stderr.
> > Theres a simple solution,
> > have a list of harmless warnings and filter the output of gcc through that
> > That would also help alot with aes.c ...
> > And it shouldnt be hard to implement it, a mere
> > gcc | egrep -v `cat harmless_warnings` instead of gcc should do
> > for aes.c
> > aes.c:[0-9]*: warning: passing argument  of '(addkey|crypt|init_multbl2|subshift|mix)' from incompatible pointer type
> > would remove all but 2 warnings
> This approach has the severe drawback that it blindly hides any new
> warnings matching that pattern.
As long as the warnings are printed, similar warnings will be missed as
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I wish the Xiph folks would stop pretending they've got something they
do not. Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-cvslog