Compiler isn't converting float to INT8 properly

For example

INT8 Function::Convertnumber(F32 number)
{ INT8 return; return = number;
}

How about you provide an example that actually compiles, to begin with? Or better yet, one that actually demonstrates the full problem, i.e. one which people could actually run and see the problem for themselves?

Oh, and showing the definitions of INT8 and F32 might have been nice, too.

For example

INT8 Function::Convertnumber(F32 number)
{ INT8 return; return = number;
}

How about you provide an example that actually compiles, to begin with? Or better yet, one that actually demonstrates the full problem, i.e. one which people could actually run and see the problem for themselves?

Oh, and showing the definitions of INT8 and F32 might have been nice, too.

the typedefs are standard

typedef signed char INT8;

typedef float F32;

the simple example is enough to illustrate the problem. The issue is float to signed char conversion of the compiler. I'm using optimization level 3 which I believe might be part of the issue but I can't change that opt. level. Will probably have to accept the compiler bug and do a rewrite.

"Will probably have to accept the compiler bug and do a rewrite."

If you're confident it's a compiler bug, you should contact Keil technical support about it. They do listen to such things (provided you give good evidence).

It illustrates a number of problems - but not the one you're claiming.

You specifically stated the C compiler - but the example is not valid C !

If you want it to be interpreted as C++, you need to ensure that you correctly inform the Compiler...

But return is a keyword in both C and C++ - so can't be used as a symbol name in either.

en.cppreference.com/.../keyword

www.catb.org/.../smart-questions.html

"I'm using optimization level 3 which I believe might be part of the issue"

Indeed - since the value of 'return' (sic) is never used, it really doesn't matter what the value is at all!

"It illustrates a number of problems - but not the one you're claiming."

Oh yes, it's almost like the code is using a mix of C, C++ and something like Delphi?

DJR

could it have something to do with "Target Options" Tab C/C++ "plain char is signed" default is passiv?

Werner

the simple example is enough to illustrate the problem.

No, it's not, because like I said before: it will not even compile.

So the only problem this could possibly illustrate is that your command of the C++ programming language is not up to your own expectations.

The reason I asked for a more fleshed-out example was that there's simply no way this is the actual function the problem you described appears in. For two reasons:

1) to exhibit any run-time problem at all, the actual problematic would have had to survive compilation. This one doesn't.

2) to exhibit the particular problem you claimed, the result of that convesion would have to have some way of making it out of that function. In this one, it doesn't.

So whatever a function with the actual problem in it looks like, it would have to be so different from the sketch you posted that the latter cannot possibly serve as an illustration of the former.

First off, I see why you (well some of you anyway) guys are getting your panties in a bunch. I quickly edited some IP code which I can not legally provide here and noticed I put return instead of a variable in the declaration, for that I apologize.

INT8 function::convertnumber(F32 number)
{ INT8 rc;

rc = number; return(rc);
}

The code is C++ and the compiler stated was correct. It compiles C++ code quite well, so for the suggestions there thanks, but not an issue whatsoever. The issue was not the compiler after all, thankfully, as that would have really been a doozy of a problem in more ways than you would like to know. It was actually a configuration issue which wasn't real easy to determine, associated with the typedef for the INT8 not being done properly as a few of you pointed out. Sorry to raise a problem that wasn't a problem. take care

It was actually a configuration issue which wasn't real easy to determine, associated with the typedef for the INT8 not being done properly as a few of you pointed out.

Would you care to elaborate?

It had to do with a configuration tool unrelated to KEIL procucts. The compiler is working as intendended, sorry again for any confusion and thanks again for responding.

It had to do with a configuration tool unrelated to KEIL procucts.

I'll take that to mean that the INT8 type was actually not, like you had posted before,

typedef signed char INT8;

but rather ended up being some variation of

typedef unsigned char INT8;

correct