[FFmpeg-cvslog] r22715 - trunk/libavcodec/bitstream.c

[Uoti Urpala]

On Wed, 2010-05-05 at 00:55 +0100, M?ns Rullg?rd wrote:
> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
> 
> >> > Otoh, there are systems with much slower malloc (OSX?).
> >> 
> >> They can blame themselves.  If it's really important to someone,
> >> linking ffmpeg with a different malloc is trivial.
> >
> > Is there a reason why they should more "blame themselves" than people
> 
> They chose to use it.  They get to live the consequences.

You're saying that people using any system with those restrictions chose
it, but people using systems with different restrictions such as stack
behavior had no choice whatsoever in the matter?

> > running systems that have problems with the arrays on stack?
> 
> Variable-length arrays on the stack are inherently unsafe.  You can't
> possibly know where your stack ends, so no checking will ever be
> sufficient.

If you insist on such an impractical "you can't be absolutely certain
about anything" attitude then you can't do _any_ operations involving
the stack. There's no qualitative difference between variable-length
arrays and any other stack use in this regard.

> > In general malloc will perform worse and result in more complex and
> > fragile code. Even if you add explicit sanity/safety checks for all
> > stack arrays the result will be simpler and more robust than with
> > malloc.
> 
> You're only saying that to contradict me.  I will not entertain your
> little troll further.

You're quick to label as trolling anything that differs from your
preferred viewpoint.