static storage class missing in stdtypes.h

[irob]

Hey everyone.  I've been fighting a bug in my RS232 code the last couple days and finally realized that I had a function return declared as "Byte", which is declared as unsigned char in the stdtypes.h.  My MCU is the MC9S08QG8.

This function returned two bytes in an array, but I noticed that the second byte kept getting trashed in RAM.  What I really needed was a static char so that the RAM would be reserved for that array.

I'm a little surprised there's not a static definition in the stdtypes header file.

[allawtterb]

---

irob wrote:
I'm a little surprised there's not a static definition in the stdtypes header file.

---

Are you saying that you are surpised that Byte wasn't a static unsigned char or that you are surprised that there was no type for a static [signed/unsigned] char?  Certainly you wouldn't want the first case as all locals defined as a Byte would be placed in RAM and retained. For the second case, I don't see why there would be a type for a static char.  Personally I don't use the stdtypes from CodeWarrior but use uintXX_t (C99) types.  Declaring a word on an S08 and having it use 16-bits seems to contradict the definition of a "word". 

[irob]

I was referring to the latter.  The reason for a static char type... convenience.  I needed a static char for my function to work as expected.  But then it's just as easy to declare the variable as "static Byte". 

[CompilerGuru]

Static is not part of the type at all, static defines how objects are allocated. Adding it to stdtypes.h is therefore not meaningful.

It sounds like your actual problem is that the C language does not return arrays per value, arrays are implicitly returned by reference.
So basically arrays just behave differently than any other kind of type in the language, well C is the way it is....
Retuning pointers to statically allocated arrays is usually not a such good idea as it opens the door for all kinds of runtime problems. When some other code calls your function and it modifies the buffer, the original result gets invalidated, and such bugs are hard to find.

Daniel

[Lundin]

I would be bold and say that there is never a reason to return an array, or even a pointer, from a function. The need to do so usually originates from flawed logic. A pointer returned from a function can point at the following kind of variables:

- Local variables. This is always a bug.

- The same data as one of the parameters of the function. This is poor programming, as the same parameter will be used twice in the function, taking up unnecessary stack space when the function is called.

- Dynamically allocated variables. Returning pointers to variables that were dynamically allocated inside the function is one of the most common causes for memory leaks in C programs. It is better to leave the allocation to the caller, or encapsulate it inside the code module.

- Global/static variables. This is a bug in a multi-process program, as it might make the function unsafe for multiple processes. Note that a microcontroller program that is using interrupts is a kind of multi-process program. In case of static variables, this is also a flaw in the program design, as it breaks the encapsulation of private variables.

Instead, return data through pointers in one of the function parameters

[CompilerGuru]

BTW.
- You can change your function to return a struct (possibly containing an array)
- pass the array in instead of returning it
- encode the two bytes in one 16 bit word and return that.

Whatever makes sense for your case.

Daniel