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: [PATCH v2.0] Use saturated arithmetic for overflow detection.

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

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