This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Strange Float Behaviour

Guys,

I am having a problem with float division using PK51. I was wondering if anyone could explain this or has seen it before.

I have a float, and want to divide it by 36000. If I do this directly, I get strange results, even -ve numbers although all the variables are +ve.

accrued_seconds =(total_accrued_seconds/36000);

Both variables are floats, however, if I do the following

accrued_seconds = (unsigned long)(total_accrued_seconds/10);

accrued_hours = (float)(accrued_seconds/3600);

I get the correct result. For some reason that I don't understand using too big a divisor in the first code causes an error but not a two step as in the second. I have also tried the two step without the cast to an unsigned long and I get the errored result.

I tired the same thing on GCC on a PC and of course it works fine.

Any clues anyone?

Cheers,

Dirk

Parents
  • I can't see why embedded compilers should not go the same route.

    Here are two possible reasons why they don't, or shouldn't.

    1) From a rather high-level point of view, it would be quite a waste of effort if every tool vendor were to re-invent half of lint. It increases overall tool costs to us all by duplicated work.

    2) Different compilers tend to need different changes to the source code to silence warnings: #pragmas, special comments, whatever. In code intended for re-use it can be nigh-on impossible to pass through all used compilers without triggering unwanted warnings.

    Ultimately the Unix gurus got it right: use one tool for one task. The tool for the task of checking C code for likely bugs is not the compiler, it's lint. Use it.

Reply
  • I can't see why embedded compilers should not go the same route.

    Here are two possible reasons why they don't, or shouldn't.

    1) From a rather high-level point of view, it would be quite a waste of effort if every tool vendor were to re-invent half of lint. It increases overall tool costs to us all by duplicated work.

    2) Different compilers tend to need different changes to the source code to silence warnings: #pragmas, special comments, whatever. In code intended for re-use it can be nigh-on impossible to pass through all used compilers without triggering unwanted warnings.

    Ultimately the Unix gurus got it right: use one tool for one task. The tool for the task of checking C code for likely bugs is not the compiler, it's lint. Use it.

Children
No data