C51: 32 bits unsigned returned values treated as signed 16 bits

Ed,

many thanks for your reply. I knew these features for having programmed DSP long time ago but it is always necessary to get a reminder ( I always forget such kind of rules ).

Before your mail I had already try to cast every single variable ( to u32 ) but it had not changed anything.

I may precise the problem as I investigated it a little bit further.

We have the function th_microSecondsNow() that return the micro-seconds elapsed since the last time we called the function.

If you do the following, the result is correct:

u32 my_local;
my_local = th_microSecondsNow() //result OK, for example 0x00120233

But imagine you want to design your program introducing interfaces, the usual_microSecondsNow() ( microSecondsNow() in the first post ) just forwards the u32 returned value, but it does it badly !:

//the usual fonction
u32 usual_microSecondsNow(void)
{
   //your device dependant function
   return th_microSecondsNow();
}

//...

u32 another_local;
another_local = usual_microSecondsNow(); // result NOK !! 0x00000233

So maybe I chose a not so adequat title for my post.
Anyway if anybody has a clue ( I am new to 8051-like µC and it blows your mind as being very different from other µC )

Another step towards understanding of the problem.

The header file containing the function th_microSecondsNow() was missing.

So the prototype ( u32 th_microSecondsNow(void); )was missing but the compiler did not complain unless with a warning

warning C206: 'th_microSecondsNow': missing function-prototype

Naturally during first steps of development the number of warning is huge and this one was completely lost among the others

As I had tried to introduce a new function:

void th_microSecondsNow_2(u32 * ptr);

I obtained an error. Why a warning in one case and an error in the other case, while the 2 functions are written one just below the other ??

error C267: 'th_microSecondsNow_2': requires ANSI-style prototype

So I may assume that with a missing prototype during compilation ( but a function present in .o object file letting the linker finish its job ) the function was treated as

int th_microSecondsNow(void);

As int on the C51 compiler is a 16 bit, and plain int always signed, it may explain the odd behaviour we had.

Naturally during first steps of development the number of warning is huge and this one was completely lost among the others

I would disagree with the assumption that you might expect a huge number of warnings during the first steps of a developments.

A sensible approach is to always treat warnings as errors until or unless you can prove otherwise.

Traditional C assumes that functions takes int parameters and returns int. And that variables without a type is int.

And this will result in big problems when you have an 8-bit processor with 16-bit int and a function that returns 32-bit unsigned.

This is a reason why using C++ (even for C-style programs) makes C++ a better C. Type-safe linking makes sure that you don't accidentally call a function with wrong parameter or return type.

I'm not sure exactly what makes the compiler decide that the uint32 pointer parameter of the second function should be giving an error while the other function without parameters should just result in a warning. Best is if the compiler is configured to upgrade all warnings about missing prototypes into full errors to avoid producing programs that looks like they should work but secretly produces broken results.

"I would disagree with the assumption that you might expect a huge number of warnings during the first steps of a developments."

I prefer iterative development, where new code is added, compiled and tested in small blocks. And warnings getting caught and analyzed as they show up. So never any large numbers of warnings. But sometimes a large number of errors, because of some syntax error.

It's best to take care of any warnings immediately, while the relevant code lines are in fresh memory. And preferably before the code is module-tested, to make sure that a late change doesn't break the code.

So the prototype ( u32 th_microSecondsNow(void); )was missing but the compiler did not complain unless with a warning

warning C206: 'th_microSecondsNow': missing function-prototype
Naturally during first steps of development the number of warning is huge and this one was completely lost among the others

'naturally' before you start anything else you get rid of all warnings

I agree with you all.
It is however explicitely written in the coding guidelines of every company, the langage be C, C++, VHDL or whatever you have.
Anyway I am using generated code and at the present time losts of warnings can not be avoided or quickly fixed.

It is however explicitely written in the coding guidelines of every company,
I know of no company with a "coding guideline" that accept a lot of warnings. I know of a case where you had to justify each and every warning you wanted to temporarily live with and more cases where warnings just were not accepted.

Anyway I am using generated code and at the present time losts of warnings can not be avoided or quickly fixed.

1) what do you mean by 'generated code'
2) if you can not fix warnings, you are lost anyhow

1) what do you mean by 'generated code'
Excel based code generation, MATLAB model based code generation which always gives QAC warnings, compiler warnings in first time integration. Single C file is auto generated based on configuration. File may be large which resulted many warnings or may be migrated to another platform.

But for this kind of auto generated code we can not generate block by block or partial to test with your module as far as i know.