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: Ping Re: Fix strtod integer/buffer overflow (bug 14459)


On Mon, 27 Aug 2012, Carlos O'Donell wrote:

> This patch adds a dozen new asserts to the various code paths.
> 
> Could you explain in some detail why the asserts are needed as
> opposed to diagnosing a condition and returning an error?

The only error permitted for strtod in errno is ERANGE (which can only be 
detected in general by setting errno before the call and testing it 
afterwards); the return value is specified for all inputs, based on 
interpreting the maximal initial subsequence of the specified form.  There 
is no way to return any kind of error other than that the specified value 
results in overflow / underflow.

The assertions are of two kinds: (a) those where assertion failure would 
indicate a bug in the code and (b) those where implementation limits are 
exceeded.  Those of type (a) (several pre-existing) help avoid bugs in one 
part of the code propagating into possible undefined behavior, including 
overflows, in the rest of the code, and make it easier for human readers 
to see what the expectations are of the code at each point.  Those of type 
(b) are more directly aimed at ensuring an integer overflow cannot occur: 
calculations where it might not be clear that there are no overflow 
possibilities have an assertion added that the following calculation does 
not overflow.

The only case where such overflows might in principle occur, and so the 
assertions fire, in the absence of bugs in the code, is for a string of 
2^61 (minus a few thousand, maybe) or more bytes.  The assertions help 
provide future-proofing against integer and buffer overflows arising if a 
string of that size becomes feasible in future, without uintmax_t having 
become 128-bit on the system on which such a string is feasible (and I 
think it's more likely such a system would have 128-bit uintmax_t).  I 
don't believe such strings are feasible at present (even given mmap tricks 
to keep them within physical memory by mapping the same pages many times) 
- a single pass through them would take years, and generally 64-bit 
architectures don't actually provide the address space to map an object of 
2^61 bytes (current x86_64 implementations limit address space to 48 bits, 
for example).

-- 
Joseph S. Myers
joseph@codesourcery.com


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