Fixed Error from 'iclamp' returning float result

[Grey Roger]

I can't remember if this was reported as part of another thread, but anyway:

I saw a message in "error.log" about an integer function returning a float result. It tracked to this:

int iClamp(int min, int max, int val)
{
   if(val < min) val = min;
   else
   {
       if(val > max) val = max;
   }
   return val;
}

The system presumably doesn't check that the arguments of a function match the type declared in the function. That caused another problem which had to be solved by using a variable inside the function. And so it is here. Something is presumably calling 'iclamp' but feeding ia float parameter to "val", and if it's within the limits, the function returns "val" unaltered - which may be a float. So:

int iClamp(int min, int max, int val)
{
   int retval = val;
   if(retval < min) retval = min;
   else
   {
       if(retval > max) retval = max;
   }
   return retval;
}

That copies "val", whatever it is, into an integer variable. Then, if the value is within the limits, it returns the variable, not the original "val".

 

[Pieter Boelen]

Clever! No clue why this happens, but we've had similar issues before and this seems like a safe solution.

 

[Levis]

you could also change the last line into:
return makeint(val);

 

[ChezJfrey]

That copies "val", whatever it is, into an integer variable. Then, if the value is within the limits, it returns the variable, not the original "val".

Yep. Seen this same type of problem. The internal compiler is not strongly typed and can sometimes return unexpected results. There was a similar bug in COAS code where a case statement returned a wrong answer, when multiplying one of the 'int' parameters by one, where the passed 'int' was originally a float. Example:

int funcA(int b){

...
case something:
return b * 1;
...

The bug arose when b was a float, it would actually return a value of b * 10.

The workaround was to do exactly what you describe. Assign b to a newly declared int c within the function and return c * 1.

 

[Pieter Boelen]

The bug arose when b was a float, it would actually return a value of b * 10.

YIKES! Congratulations on figuring that out. Sounds like a tricky one.

 

[Levis]

@Grey Roger you fixed this in your version right? going to mark this fixed.

 

[Grey Roger]

Yes, the correction which I posted is of course in my own installation, and is going into the update archive.