Bug 211654 - Calling KLocale::formatNumber() with very high precision takes forever
Summary: Calling KLocale::formatNumber() with very high precision takes forever
Status: RESOLVED UPSTREAM
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdecore (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-24 16:13 UTC by Alex Richardson
Modified: 2018-11-05 09:24 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Proposed patch (722 bytes, patch)
2010-02-23 23:36 UTC, Christoph Feck
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Richardson 2009-10-24 16:13:08 UTC
Version:            (using KDE 4.3.2)
Compiler:          GCC 4.3 
OS:                Linux
Installed from:    SuSE RPMs

When calling KLocale::number() with a very high precision (I tried 100.000.000) will max out CPU and take forever.
Same goes for QString::number().

Probably the best solution would a maximum value for precision. For example something like 200-300 since doubles can't have such a high precision.

Qt version is 4.5.3
Comment 1 Christoph Feck 2009-10-24 18:28:19 UTC
I assume you mean KLocale::formatNumber()

200-300 is way too big, too, "double" has a precision of about 16 digits... And "precision" is the number of fractional decimal digits, so it usually doesn't make sense to have more than 10 or so.

If you are going to process numbers with higher precision than about 16 digits, then use libgmp or something similar.
Comment 2 Alex Richardson 2009-10-24 18:36:31 UTC
(In reply to comment #1)
> I assume you mean KLocale::formatNumber()
> 
> 200-300 is way too big, too, "double" has a precision of about 16 digits... And
> "precision" is the number of fractional decimal digits, so it usually doesn't
> make sense to have more than 10 or so.
> 
> If you are going to process numbers with higher precision than about 16 digits,
> then use libgmp or something similar.
The problem was I called it with such a high precision by mistake and it hung the whole program. 
I never wanted to have such an exact representation.
I just thought it might keep other applications from hanging if an upper bound gets added.
Comment 3 Christoph Feck 2010-02-23 23:36:58 UTC
Created attachment 41044 [details]
Proposed patch
Comment 4 Alex Richardson 2010-02-24 00:30:42 UTC
Looks good, will you backport to 4.4?
Comment 5 John Layt 2010-08-07 20:37:16 UTC
Christoph, it doesn't appear this was ever committed?  Should we do this for formatMoney() as well?   Should we be validating the input to setDecimalPlaces() and setMonetaryDecimalPlaces() as well?

Cheers!
Comment 6 Christoph Feck 2010-08-07 21:48:59 UTC
I asked for review on IRC some time ago, and for the specific function, it was proposed that Qt should make sure not to generate numbers with too many decimal digits in the first place. That's why I did not applied the patch, I also did not file a Qt bug, though.

I do not know the other functions, so if they need some argument sanity checking, please go ahead.
Comment 7 Andrew Crouthamel 2018-11-05 03:07:52 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 8 Alex Richardson 2018-11-05 09:24:58 UTC
Since KLocale is now only in kdelibs4support and the function in question only calls the Qt code I think we should report this as an upstream bug if it still applies. I don't have access to my dev environment right now to test but if I can see if it still happens with Qt5.12 and if so report it upstream.