This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2.0] Use saturated arithmetic for overflow detection.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, <libc-alpha at sourceware dot org>
- Date: Tue, 5 Nov 2013 15:18:04 +0000
- Subject: Re: [PATCH v2.0] Use saturated arithmetic for overflow detection.
- Authentication-results: sourceware.org; auth=none
- References: <20131030174502 dot GA18107 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1310301749400 dot 22878 at digraph dot polyomino dot org dot uk> <20131030183318 dot GA18706 at domone dot podge> <20131101133126 dot GA2546 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1311011640530 dot 24652 at digraph dot polyomino dot org dot uk> <20131105102226 dot GB21063 at domone dot podge>
On Tue, 5 Nov 2013, Ondrej Bilka wrote:
> > In my view, we shouldn't optimize this with inline asm at all. For any
> > optimizations, work on getting appropriate built-in functions into GCC
> > (making sure that they do get optimized there based on constant arguments,
> > so that the overflow flag is used only when it's the most efficient
> > approach) and then use those functions in glibc (architecture-independent
> > file) conditional on the GCC version.
> >
> I could omit assembly optimizations but then do not argue about
> performance impact. As results are used in malloc which is around
> hundred times slower than performance lost effect is small. If function
> allocates memory in two places then you should merge these allocations
> into one which has better performance gain/added complexity ratio.
I would be happy to optimize purely for human comprehension of the code,
unless and until someone finds significant performance impact for
real-world glibc function calls. That is, do such checks anywhere an
allocation size is calculated (in a way that avoids divisions for constant
inputs, but has no architecture-specific optimizations), unless it is
clear to a reader of the code that no overflow can occur (and then put in
a comment about why no overflow check is needed).
(It would still be desirable for someone to assess all the fixed locations
for possible security impact, to work out which cases might merit CVEs and
backports of fixes.)
--
Joseph S. Myers
joseph@codesourcery.com