Bug in ConsoleInternal.cc?
by Samme Ng · in Torque Game Engine · 09/08/2005 (8:53 pm) · 9 replies
I am using a large number: 300000001 in the script, however, when I using it to & 255, it is always result in zero.
After tracing the code, I found one possible problem:
The ival is converted from fval, which MUST be losing details (3.0 e+8). What is the reason not using ival = (U32)dAtoi(value);? Is it a bug? Or is it fixed in latest HEAD?
After tracing the code, I found one possible problem:
void Dictionary::Entry::setStringValue(const char * value)
{
if(type <= TypeInternalString)
{
// Let's not remove empty-string-valued global vars from the dict.
// If we remove them, then they won't be exported, and sometimes
// it could be necessary to export such a global. There are very
// few empty-string global vars so there's no performance-related
// need to remove them from the dict.
/*
if(!value[0] && name[0] == '$')
{
gEvalState.globalVars.remove(this);
return;
}
*/
fval = dAtof(value);
ival = (U32)fval; // <<<<< BUG?The ival is converted from fval, which MUST be losing details (3.0 e+8). What is the reason not using ival = (U32)dAtoi(value);? Is it a bug? Or is it fixed in latest HEAD?
#2
09/09/2005 (3:56 am)
Fixed. dAtoi was correct.
#3
-Ron
09/09/2005 (4:38 am)
There are number of places in code were TGE converts from float to int (etc..), which cause all kinds of compiler warnings. This is could be a valid solution to silence all those annoying warnings forever ;) (or just turn off warnings all together ;) )-Ron
#4
$h = 300000001;
$t = $h - 300000000;
echo($t);
should result 0
It is because that through out the calculation, it pick $h's float (fval = 3e+008) for calculation, which result in wrong value.
However, as TGE's script doesn't care the variable type, taking them as float will limit the value's range. How do you think to fix?
09/09/2005 (9:24 am)
I do have a question, which asked in other thread, it is the problem of using float through out calculation in script.$h = 300000001;
$t = $h - 300000000;
echo($t);
should result 0
It is because that through out the calculation, it pick $h's float (fval = 3e+008) for calculation, which result in wrong value.
However, as TGE's script doesn't care the variable type, taking them as float will limit the value's range. How do you think to fix?
#5
09/09/2005 (9:31 am)
I tested that case after using dAtoi, and it works fine. I have already applied another fix to 1.4 that addresses that overflow case.
#7
09/09/2005 (4:34 pm)
Yes, as I said, in RC2 I can run that code properly and get 1 as the answer.
#8
Since I have modified some sources files for bug fix and enhancement, I can't upgrade my code directly (may be by mergering those codes).
09/10/2005 (8:21 am)
Ok. Is it changed a lot of codes to fix these problem?Since I have modified some sources files for bug fix and enhancement, I can't upgrade my code directly (may be by mergering those codes).
#9
09/11/2005 (6:47 pm)
Do a search and replace for %f and change it to %g; this fixes a lot of problems. 
Associate Kyle Carter