views:

113

answers:

4

im working on a c lib which would be nice to also work on embedded systems but im not very deep into embedded development so my question

are most embedded compilers able to cope with local static variables - which i would then just assume in further development OR is there a #define which i can use for a #ifdef to create a global variable in case of

thx

+2  A: 

They should, as local static variables are part of the C standard.

Of course, there is nothing preventing them from creating a C-like language that does not have all the features. But since that would be non-standard, then the way to identify that a feature is lacking would be non-standard as well.

R Samuel Klatchko
+1  A: 

Since static variables are part of the standard, you should be safe.

The problem with support is probably not to be found with your compiler (most of which handle the standard pretty well), but with whatever code you have to set up your runtime environment. Make sure that when you're loading the code that you properly unpack the executable, read-only data, read-write data, and zero-init sections of the executable before jumping into the C code.

Carl Norum
A: 

Local static variables are part of th C standard, so yes.

\pedantic{

If your code is well organized, with separate files (compilation units) for different subsystems, you might do better to have a static variable with file scope. This will make it easier to factor the code that uses it into separate functions. If the code that uses the variable is complicated, this will permit you to split it into smaller static functions, which are easier to read, understand and debug.

}

Tim Schaeffer
A: 

Yes. local statics are really not much different than globals once the compiler is done chewing on your source code. I could think up exotic processors where globals would be an issue, but I doubt you will encounter many.

The truly interesting thing about globals on embedded processors is that you often have the option of having the compiler allocate them in ROM, EEPROMs, etc.

T.E.D.