Re: [PATCH] Use malloca instead alloca

[Paul Eggert <eggert at cs dot ucla dot edu>]

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:

   size_t n = ... some big number ...;
   char *p = malloca (n);
   strcpy (p + n - 10, "x");
   freea (p);

This might not SEGV when malloca returns NULL, depending
on the architecture; for example, if n happens to be
100000010 and (char *) 100000000 happens to be a valid address.

> 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.

> Of course. In this benchmark
> http://kam.mff.cuni.cz/~ondra/malloca_benchmark.tar.bz2
> 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.

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.