On Sat, Dec 29, 2012 at 06:21:55PM -0800, Paul Eggert wrote: > On 12/29/2012 11:18 AM, Ondřej Bílka wrote: > > > alloca caused segfault on oom condition and null pointer > > access has equivalent behaviour. > > alloca doesn't always cause a SEGV on out of memory. > That's part of the problem that we're trying to cure. > If alloca is given too large a number, it might SEGV, > and it might not. malloca should not have this problem: > it should reliably fail when out of memory. > > Unfortunately when out of memory the proposed use of > malloca does not reliably SEGV. Here's a trivial example: > On my example I checked it causes null access. But you are rigth it cannot be done in general. > > > And on linux it will always succeed and be killed by oom later. > > Sorry, I'm not following, or perhaps I'm misunderstanding you. > malloc does not always succeed on GNU/Linux; it sometimes > returns NULL. malloc (SIZE_MAX) is a trivial example of this.
It was a example why oom condition cannot be detected reliably. > > > with my implementation is 20% faster than gnulib one. > > First, we need a correct implementation before we can start > doing benchmark comparisons, as fixing the problems will slow > things down, I expect. It's not just the SEGV problem > mentioned above; it's also the problem with very large > allocation requests that I mentioned earlier. OK In http://kam.mff.cuni.cz/~ondra/malloca_benchmark.tar.bz2 I changed signal from SEGV to ABRT and sizes. No measurable performance drop. > > Second, that benchmark invokes malloca on a constant. But > actual code rarely does this: > > char *p = alloca (100); > > as what would be the point? It's more portable to do this: > > char buf[100]; > char *p = buf; > > and one doesn't need either alloca or malloca in this case. > A more-realistic benchmark would invoke malloca with a > non-constant, as that's how alloca is typically used in > practice. Now passing size by variable and this does not change performance ratio.
