| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 6 | |
Hi,
I've run across a problem converting certain numerical values (double)
to QStrings via any of the standard mechanisms (operator<< on a
textStream, QString.setNum, QLocale-related toString methods etc.).
I've verified the problem on QT 4.2.1, 4.2.2 and 4.2.3 under Linux. It
does *not* manifest itself on Qt/Mac 4.2.0, although I don't have an
easy way of checking whether it's the Mac version or version 4.2.0 that
isn't affected.
To reproduce, consider the following program:
_____________
#include <QTextStream>
#include <QFile>
#include <stdio.h>
int main(void) {
QFile file;
file.open(stdout, QIODevice::WriteOnly);
QTextStream stream(&file);
stream << 3e-09 << "\n";
stream << 6e-09 << "\n";
stream << 9e-09 << "\n";
file.flush(); file.close();
}
______________
I would expect this to produce (after `qmake -project ; qmake ; make ;
./test`) the following output:
3e-09
6e-09
9e-09
However, instead I get this:
2.:e-09
5.:e-09
9e-09
Note the strange ':' character in the output, which makes this a
syntactically incorrect double. As I said, the same incorrect QString
result can be produced in a variety of different ways, which all seam to
rely on qdtoa() and _qdtoa(). If you cast the double to float, the
correct string is printed. In some cases (in particular, in the example
above -- but not for all such problematic numbers), multiplying the
double by 10 and then dividing by 10 results in the correct string.
Has anyone seen this problem before? Is it reproducible? How could I
avoid it?
Cheers,
- Pavel
--
[ signature omitted ]
On Sunday 22 April 2007 13:24:19 Pavel Avgustinov wrote:
> Hi,
>
> I've run across a problem converting certain numerical values (double)
> to QStrings via any of the standard mechanisms (operator<< on a
> textStream, QString.setNum, QLocale-related toString methods etc.).
>
> I've verified the problem on QT 4.2.1, 4.2.2 and 4.2.3 under Linux. It
> does *not* manifest itself on Qt/Mac 4.2.0, although I don't have an
> easy way of checking whether it's the Mac version or version 4.2.0 that
> isn't affected.
>
> To reproduce, consider the following program:
>
> _____________
> #include <QTextStream>
> #include <QFile>
> #include <stdio.h>
>
> int main(void) {
> QFile file;
> file.open(stdout, QIODevice::WriteOnly);
> QTextStream stream(&file);
> stream << 3e-09 << "\n";
> stream << 6e-09 << "\n";
> stream << 9e-09 << "\n";
> file.flush(); file.close();
> }
> ______________
>
> I would expect this to produce (after `qmake -project ; qmake ; make ;
> ./test`) the following output:
>
> 3e-09
> 6e-09
> 9e-09
>
> However, instead I get this:
>
> 2.:e-09
> 5.:e-09
> 9e-09
>
> Note the strange ':' character in the output, which makes this a
> syntactically incorrect double. As I said, the same incorrect QString
> result can be produced in a variety of different ways, which all seam to
> rely on qdtoa() and _qdtoa(). If you cast the double to float, the
> correct string is printed. In some cases (in particular, in the example
> above -- but not for all such problematic numbers), multiplying the
> double by 10 and then dividing by 10 results in the correct string.
>
> Has anyone seen this problem before? Is it reproducible? How could I
> avoid it?
I think you may be seeing a miscompilation. Can you try the patch below?
Simon
--- a/src/corelib/tools/qlocale.cpp
+++ b/src/corelib/tools/qlocale.cpp
@@ -44,7 +44,7 @@
#if !defined(QT_QLOCALE_NEEDS_VOLATILE)
# if defined(Q_CC_GNU)
-# if __GNUC__ == 4 && __GNUC_MINOR__ == 0
+# if __GNUC__ == 4
# define QT_QLOCALE_NEEDS_VOLATILE
# elif defined(Q_OS_WIN)
# define QT_QLOCALE_NEEDS_VOLATILE
Attachment:
Attachment:
pgp9UsDn7ZM83.pgp
Description: PGP signature
Message 3 in thread
Hi,
Accidentally replied off-list... here is the resolution of this issue.
Simon, thanks very much for your help!
Cheers,
- Pavel
Simon Hausmann wrote:
> On Sunday 22 April 2007 23:20:27 you wrote:
>
>> Simon Hausmann wrote:
>>
>>> I think you may be seeing a miscompilation. Can you try the patch below?
>>>
>>> Simon
>>>
>>> --- a/src/corelib/tools/qlocale.cpp
>>> +++ b/src/corelib/tools/qlocale.cpp
>>> @@ -44,7 +44,7 @@
>>>
>>> #if !defined(QT_QLOCALE_NEEDS_VOLATILE)
>>> # if defined(Q_CC_GNU)
>>> -# if __GNUC__ == 4 && __GNUC_MINOR__ == 0
>>> +# if __GNUC__ == 4
>>> # define QT_QLOCALE_NEEDS_VOLATILE
>>> # elif defined(Q_OS_WIN)
>>> # define QT_QLOCALE_NEEDS_VOLATILE
>>>
>> Tried it -- you're quite right, with this patch double-to-string
>> conversion works correctly!
>>
>> Now, I'm still a little confused about what the "proper" fix would be.
>> Is this a Qt bug (and will the patch make it into the next release)? The
>> libraries I tried were Debian-packaged ones; is it a compilation issue
>> with these packages? Also, I saw the problem with a static version of Qt
>> I compiled myself; what should I have done differently, if anything?
>>
>
> Strictly speaking this is a Qt bug because the code in qlocale.cpp does some
> very evil casts and as a result newer versions of gcc seem to miscompile the
> code when compiling with optimizations. I've notified the distro packagers
> about the workaround and I hope they'll include it. The workaround is also
> included in the current Qt 4.3 snapshots.
>
>
> Simon
>
>
--
[ signature omitted ]