Project

General

Profile

Actions

Bug #1169

closed

bug in WebUtils.C::round_str()

Added by Tassilo Glander about 12 years ago. Updated about 12 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
02/20/2012
Due date:
% Done:

0%

Estimated time:

Description

Hi,

the function returns wrong strings ("0.0000000") in case of input doubles above a certain value. Try for example 3000.0.

This is because of an overflow of the int flipping to a negative value. It can be fixed using a long int to store intermediate results:

WebUtils.C::round_str()

old version:

  int i = static_cast<int>(d * exp[digits] + (d > 0 ? 0.49 : -0.49));
  itoa(i, buf);

fixed version:

  long int i = static_cast<long int>(d * exp[digits] + (d > 0 ? 0.49 : -0.49));
  lltoa(i, buf);

Alternatively, it might be worth considering to use boost for the lexical cast and rounding functionality (maybe more robust).

Best,

Tassilo

Actions #1

Updated by Wim Dumon about 12 years ago

Hello Tassilo,

I suppose this is in combination with WebGL?

The reason that we don't use boost there is performance. The C streams have to take so much cruft (configuration options) into account that they become really slow in making these conversions. But indeed we should replace it by something that actually works. I applied your patch.

Best regards,

Wim.

Actions #2

Updated by Tassilo Glander about 12 years ago

Hello Wim,

yes indeed :). I had vertices with coordinates like this. Thanks for applying the patch.

Interesting to know about the perfprmance problem in boost casts.

Best,

Tassilo

Actions #3

Updated by Koen Deforche about 12 years ago

  • Status changed from New to InProgress
  • Assignee set to Wim Dumon
  • Target version set to 3.2.1

Wim,

Can you commit the fix?

Tassilo: the various methods in Utils.C all started as a way to get significant performance improvements, guided by real performance issues on low-end embedded systems, as replacements for straight implementations using for example boost::lexical_cast<> or plain C itoa() functions.

One major source for slow-downs in stream-based string conversion (using boost::lexical_cast<>) is locale processing.

As is typical for these replacements is that initially they were conceived for a specific use-case, but later got use-cases that no longer fit their limitations... and that's how bugs get born :-)

Regards,

koen

Actions #4

Updated by Koen Deforche about 12 years ago

  • Status changed from InProgress to Resolved
Actions #5

Updated by Koen Deforche about 12 years ago

  • Status changed from Resolved to Closed

Fixed in 3.2.1

Actions

Also available in: Atom PDF