On 05/16/2016 12:19 PM, Jakub Jelinek wrote:
On Mon, May 16, 2016 at 12:12:38PM -0600, Jeff Law wrote:
On 05/06/2016 09:19 AM, Jakub Jelinek wrote:
On Fri, May 06, 2016 at 11:11:29PM +0800, Marcel Böhme wrote:
+ dpi.copy_templates
+ = (struct d_print_template *) malloc (((size_t) dpi.num_copy_templates)
+ * sizeof (*dpi.copy_templates));
+ if (! dpi.copy_templates)
+ {
+ d_print_error (&dpi);
+ return 0;
+ }
Another thing to consider is if the common values of dpi.num_*
and similarly in the other block are small enough, it might be desirable
to just use an automatic fixed size array (or even alloca) and only
fall back to malloc if it is too large.
Please, no, don't fall back to alloca like this. That coding idiom has been
the source of numerous security exploits in glibc. Experience shows us that
we are not capable of doing that correctly on a consistent basis.
Falling back to fixed size buffer is something we use heavily in gcc, and
are able to get it right, there is nothing hard in it.
Conceptually I agree, it ought not be that hard, in practice, it's been
an absolute disaster in glibc.
I've often wondered if the right model is to to use escape analysis
along with the size of the object, loop analysis, etc and let the
compiler figure this stuff out rather than leaving it to humans.
For the cases where we can't use malloc at all and we'd need too much memory
that it won't fit into the static buffer, I think all we can do is fall back
into increasing the time complexity in the demangler by processing the
string multiple times.
Probably true.
jeff
