This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: alloca vs malloc

On Fri, May 16, 2014 at 03:37:44PM -0600, Jeff Law wrote:
> On 05/16/14 14:31, OndÅej BÃlka wrote:
> >
> >>Moreover, turning alloca failures into "reliable crashes" is not a
> >>solution. If an operation requires allocation which could fail, it
> >>must be able to back out whatever work it already did and report
> >>failure. Crashing is not an acceptable implementation.
> >>
> >No, when it is third party codebase and it does not want to rewrite
> >existing code do you have a better proposal?
> alloca is typically going to be expanded inline by the compiler.
> Calls from a 3rd party library into any glibc implementation of
> alloca should be rare enough that they're a "don't care"
> situation...
> And to be clear, when I want to ban alloca, I'm referring to uses
> within glibc itself.
I did not talked about glibc alloca but alloca in general.

For libc there are better alternatives, I will add priority to malloca
cleanup. As glibc code is now alloca are mostly
trivial or following this pattern occuring about hundred times:

            else if (__libc_use_alloca (len * sizeof (wchar_t)))
              string = (CHAR_T *) alloca (len * sizeof (wchar_t));
            else if ((string = (CHAR_T *) malloc (len * sizeof (wchar_t)))    
                     == NULL)
                done = -1;
                goto all_done;
              string_malloced = 1;

Then there are extend_alloca patterns.

As now a risk of manually rewriting alloca could introduce bugs and
decrease performance so it is unlikely a improvement.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]