Re: [PATCH] malloca v2

[Roland McGrath <roland at hack dot frob dot com>]

There are numerous style problems I won't bother to enumerate.  Someone
else might be more in the mood to repeat all the same stuff that anybody
who has sent more than two patches to this list ought to have picked up
already by now.

You're using __attribute__ ((cleanup)) wrong, suggesting you
haven't actually tested this properly.

I'm only interested in something to be used by libc internals.  So
conditionals about any other kind of use are just cruft in the way of
useful review for libc purposes.

A quick glancing audit of all the uses of __libc_use_alloca shows that few
of them are used in loops and the like.  Uses without loops don't need such
complexity in the cleanup function, because there is just one block to
free.  Of the uses in loops, some already use something more complex like
extend_alloca and/or alloca_account, so that those could not be converted
to your API without losing some of the more sophisticated adaptive behavior
they have now.

I'm not really interested in any new internal API that doesn't address all
the kinds of uses we already have.  That means supporting the uses that
today use extend_alloca and alloca_account.

Preemptively fiddling with the implementation like you are doing seems like
a waste of effort to me.  The sensible path to anything that will actually
be accepted in libc would start with doing a thorough audit of the uses of
alloca that exist in the libc code today, categorizing them by how complex
the usage patterns are and the details of those complexities.  Only from
that information can one evaluate an API proposal to see how it compares in
maintainability to what we have now across all the categories.  If
something handles all the uses adequately and is clearly easier to use for
at least many of them, then it will merit serious consideration.  That
consideration will require analysis of the generated code to see how it
compares to what we get today, and we'll only accept it if the code is at
least as good or is only slightly worse in some corner cases if that's
justified by a great improvement in maintainability.


Thanks,
Roland