Hi @llvm,
I stumbled over a strange behavior if a float containing a NaN is
printed (e.g. in the clang rewriter). The local template method
"append"
in APFloat.cpp deduces the size from the char array, which for "NaN"
is
4 (including the trailing zero). If APFloat::toString is called with a
SmallString and then SmallString::str() is called, it returns "NaN\0".
I
guess that this is not intended. Maybe it can be fixed by the simple
patch attached.
Best regards
Olaf Krzikalla
-------------- next part --------------
Index: lib/Support/APFloat.cpp
==================================================================---
lib/Support/APFloat.cpp (revision 160546)
+++ lib/Support/APFloat.cpp (working copy)
@@ -3278,16 +3278,10 @@
}
namespace {
- static void append(SmallVectorImpl<char> &Buffer,
- unsigned N, const char *Str) {
- unsigned Start = Buffer.size();
- Buffer.set_size(Start + N);
- memcpy(&Buffer[Start], Str, N);
- }
template <unsigned N>
void append(SmallVectorImpl<char> &Buffer, const char
(&Str)[N]) {
- append(Buffer, N, Str);
+ Buffer.append(Str, Str + N - 1);
}
/// Removes data from the given significand until it is no more
On Tue, Jul 24, 2012 at 3:06 AM, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de> wrote:> Hi @llvm, > > I stumbled over a strange behavior if a float containing a NaN is printed > (e.g. in the clang rewriter). The local template method "append" in > APFloat.cpp deduces the size from the char array, which for "NaN" is 4 > (including the trailing zero). If APFloat::toString is called with a > SmallString and then SmallString::str() is called, it returns "NaN\0". I > guess that this is not intended. Maybe it can be fixed by the simple patch > attached.Thanks for the diagnosis. Do you have a test case to go along with this? The simpler fix seems to be to untemplate this code & have "append" take a StringRef. We can just rely on the compiler to optimize away the strlen in StringRef's (const char*) ctor as we do across the rest of the codebase. That way this won't go awry if append is called with a large buffer or a string without a nul terminator, etc. - David
Am 24.07.2012 18:50, schrieb David Blaikie:> Do you have a test case to go along with this?Unfortunately not. It just popped up as a result of a programming error made by me.> The simpler fix seems to be to untemplate this code& have "append" > take a StringRef. We can just rely on the compiler to optimize away > the strlen in StringRef's (const char*) ctor as we do across the rest > of the codebase. That way this won't go awry if append is called with > a large buffer or a string without a nul terminator, etc.This is of course fine, too. Best regards Olaf