This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
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