This is the mail archive of the libc-alpha@sourceware.org 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: [PATCH] Don't bind to registered ports in bindresvport


On 6/6/2012 6:05 PM, Roland McGrath wrote:
> After this, please use an appropriate Subject: for this general
> discussion.
> 
>> First draft: 
>> http://sourceware.org/glibc/wiki/Style_and_Conventions#Alloca_vs._Malloc
>
>> 
> I think policy details should be posted on this list rather than just
> on the wiki, for easier discussion.  The wiki is a good place to
> record information once we've settled on it, but it's not a good
> place to hash it out from scratch.
> 
> The draft doesn't even mention __libc_use_alloca et al.

That's because I don't have any idea what that function does :-)

Let's start with this:

~~~
== Alloca vs. Malloc ==

The use of alloca vs. malloc must be evaluated on a case-by-case basis. There are many things to consider when looking at using alloca or malloc.

 * Is this a hot path with a small allocation? If it is then it is very likely a good candidate for using alloca, using malloc would slow down the fast path too much.

 * What is stored in the alloca'd space? Is there a security issue inherent in placing this information at a known offset from the stack pointer? If there is then it might call for using malloc.

 * Is the allocated space large? The use of alloca in glibc is limited and large allocations will need to be taken from malloc.

 * Does the API allow returning ENOMEM? The use of malloc introduces the possibility that the allocation might fail. If the API doesn't allow ENOMEM to be returned then it might be better to use alloca unless there are other circumstances.

At present there is no magic bullet of special procedure for selecting alloca vs. malloc, if there was then we could encode it into this wiki or into a macro.
~~~

What else do we need?

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026


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