[MPlayer-dev-eng] [RFC] libnut demuxer API

[Michael Niedermayer]

Hi

On Thu, Sep 08, 2005 at 05:33:02PM +0300, Oded Shimon wrote:
> On Thu, Sep 08, 2005 at 03:27:14PM +0300, Ivan Kalvachev wrote:
> > 2005/9/8, Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > > Hi,
> > > On Wed, Sep 07, 2005 at 11:44:39PM +0200, Aurelien Jacobs wrote:
> > > > On Wed, 7 Sep 2005 08:45:59 +0300
> > > > Oded Shimon <ods15 at ods15.dyndns.org> wrote:
> > > > > ahem, yes, malloc :)
> > > > > even if you run out of ram, in linux, malloc STILL doesn't fail :P
> > > >
> > > > That's plain wrong !!
> > > [...]
> > > > aurel at homer:~/x$ gcc -Wall -o x x.c
> > > > aurel at homer:~/x$ ./x 100000000
> > > > 0x2aaaaae02010
> > > > aurel at homer:~/x$ ./x 1000000000
> > > > (nil)
> > > 
> > > You have been testing whether an application can malloc any amout of
> > > RAM, which of course is not the case. Oded was talking about whether
> > > malloc can/will fail when you have no more free RAM, which is a
> > > different thing!
> > 
> > Anyway, not using malloc is radiculous. 
> > 
> > Linux uses an optimistic allocation, that is actually allocate-on use.
> > The side effect is that if program allocate more than possible amount
> > and they claim it, there won't be enough memory. When such situation
> > occurs an memory must be freed, usually by killing an process
> > (OOM_Kill). It could be the biggest&new, or the process that tries to
> > use the memory.
> > 
> > The whole point is that it doesn't matter if libnut or the program
> > allocates memory. They will behave the same way.
> > So use malloc, check for null pointer, and be happy.
> 
> Umm, I've forgoten what was the point?
> 
> I said that 'nut_demuxer_init' can never fail. Rich pointed out that it 
> does a malloc, and can possibly fail, all I was saying, malloc will most 
> likely not fail. :) There aren't ANY checks anywhere in libnut for malloc 
> returning NULL pointer, because it's pointless. Data is immedeately written 
> after the malloc, and program will crash for trying to write to NULL. A 
> crash is just about as good as a silly error message "out of memory", as 
> that never happens anyway (if it does, you got bigger problems to worry 
> about :).

well, no i disagree
* a lib should not die if it runs out of memory, as it might be due to buggy
parameters / buggy input stream which cause it, for example a input file with
1<<31 streams or so, its nonsense but should not lead to a crash of the app
just imagine a video editor which has unsaved stuff
* if the first write happens to NULL+x where x can be controled by an input
stream then you have a problem

[...]
-- 
Michael