Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Math bug in Borland compilers.

Math bug in Borland compilers.

Math bug in Borland compilers.


Some months ago I found a bug (I think) in all Borland compilers I tried.

Consider this function :

int Bug()
double a;
int c;


return c;

You can expect than this function returns 90, but it returns 89!
If you replace "c=a*(3000.0/2500.0);" for "c=a*((float)3000.0/(float)2500.0);" or for "c=a*3000.0/2500.0;" then it returns 90 correctly. Also if you declare c as float works well too.

I have tried this in TC 3.0, Borland C++ 5.02 and Builder 4. With Microsoft Visual C++ 6.0 doesn't happen. I had reported this to Borland on Feb. 25th and haven't received response yet! :-(

Can anyone try this in Builder 5?

RE: Math bug in Borland compilers.

This again proves the value of separating the sheep and the goats. Mixing types 'should normally be safe' as the compilers will jump through hoops to accomodate our coding 'sins', coverting types, etc.  :)  This is an interesting one, though most of these 'error animals' do an implicit float or double to int conversion to hilight the 'fault'. MS had similar problems a few years back with Excel calculations (which one assumes was written in MS C++), giving divide errors on integer values!

RE: Math bug in Borland compilers.

I had seen a similar effect. I got different results running a program in the IDE and as standalone. I think that is a problem of the run time Library.


RE: Math bug in Borland compilers.

Instead of getting 90 , you are getting 89 . it is because it you look at the storage method . The double stores it as 80.999999 something depending upon the system.
I have a code , just run it. And find the answer .
#include <stdio.h>
int main() {
    float a = 3.7;
    if (a == 3.7)
        printf("A is 3.7\n");
        printf("Not 3.7 ");
    return 0;

Siddhartha Singh

Siddhartha Singh

RE: Math bug in Borland compilers.

Is more than a storage method problem. The following example return 90.

int Bug()
double a,b;
int c;


return c;

Th only diference is the usage of 'b'.

Ferran Casarramona

RE: Math bug in Borland compilers.

then it could be a bug. But amazingly, when b is assigned to an int c. The value changes to 90. Is it??? Did you check thru breakpoints that when the value is assigned to b then it has 89  and when b is assigned to c the value of c is 90. If this is happening then we must inform Borland.
But this is just amazing.

Siddhartha Singh

RE: Math bug in Borland compilers.

No, 'b' is assigned 90. I have inspected the assembler code and I think I have found the solution:

 Borland and Microsoft compilers generate the same code :

0040144B DD 05 28 51 41 00   fld        qword ptr[00415128]     ; constant = 1.2 (note than in binary have not an                                                                                                                                                                                       ; exact representation)
00401451 DC 4D 80                fmul      qword ptr [a]                ; Multiply
00401454 E8 57 0B 00 00       call        _ftol (00401fb0)            ; Conversion to int
00401459 89 85 74 FF FF FF  mov       dword ptr [c],eax          ; assigning to int.

but after multiply, Borland gives a result of 89.99999999999... and Microsoft give 90.0000000000. The reason for this is than Borland works with more precision, (the Precision Control (PC) bits of the FPU "Control Word" is marked to use 64 bits precision by Borland programs and 53 bit precision by Microsoft programs), so the result is not rounded to 90 after the multiply operation. (I had found this technical details about i486 processors and compatibles at http://www.x86.org/intel.doc/486manuals.htm )

I still don't understand why when assigning to a double the result is rounded to 90, but not if is assigned directly to a int. I suppose than the FPU work internally with more precision than "double" type and no rounded operations are made.

Now the question is : Is best use high precision inside FPU than in memory as Borland does? Or is better use the same precision to get the same results if we use memory variables or FPU registers?

Ferran Casarramona

RE: Math bug in Borland compilers.


    It will depend on what you are looking for. If you are just going to round to the nearest integer, then less decimal precision is best. If you need to carry the decimal out then the reverse is best. It is up to the programmer to make these decisions and the programmer should be aware of how to squeeze the best out of the compiler.

    As a side note, I notice in the June issue of C/C++ Users Journal that there is an article by Pete Becker on Floating Point Basics. I haven't read the article yet so I can't say if it applies here but it may explain some things.

James P. Cottingham

International Veneer Co., Inc.
All opinions are mine alone and do not necessarily reflect those of my employer.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close