Embedded Systems Design - July 2008 - (Page 23)

Listing 3 Example where the guideline is followed. ist. Source ﬁles contain deﬁnitions of functions and variables, in other words, the implementation of a module. A source ﬁle can contain #include directives to header ﬁles. A header ﬁle contains only declarations of functions, variables and types, no deﬁnitions. A header ﬁle can also #include other header ﬁles. Any other use of the #include directive leads to confusion. An exception to this rule is the deﬁnition of an inline function: that deﬁnition must be in the header ﬁle; otherwise, it’s not possible to inline the function at the place where it is called. Header ﬁles should have the ﬁle extension .h. Source ﬁles should have the ﬁle extension .c. Hence, any use of the #include directive that doesn’t conform to this pattern should be expanded. Declarations should be moved to a header ﬁle that is #include’d in the source ﬁles calling the function or accessing the variable. For an example and counterexample, see Listings 1 and 2. Example #3—Guideline: keep variables local. Variables in C can be declared local to their surrounding block, or they can be declared global (by using the “extern” keyword or by declaring it outside of a function). In CleanC, global variables should not be used. The problem with using global variables is that accesses to global variables aren’t explicitly visible in function calls. This problem makes understanding of the dependencies between function calls and other expressions very hard. Tools can’t assure us that global variables aren’t being accessed by functions (such as library functions) whose deﬁnitions the tools can’t see. A call to such a function makes all global variables “call clobbered.” That means that the function is assumed to read and write all global variables, thereby introducing many unnecessary dependencies. This may unnecessarily block transformations. Instead, in int f (int x) { } void g (int* x) { *x = f(*x) + 1; } void h () { int x; x = ; g(&x); = x; } // reads x // Reads and writes to x are explicit // Reads and writes to x are explicit Listing 4 Counterexample, in other words, where the guideline is not followed. int x; int f () { } void g () { x = f() + 1; } void h () { x = ; g(); = x; } // reads x // Indirectly reads x // Indirectly writes x • www.embedded.com | embedded systems design | JULY 2008 23 http://www.smxrtos.com/processors http://www.smxrtos.com/processors http://www.smxrtos.com/eval http://www.smxrtos.com/demo http://www.embedded.com

Table of Contents Feed for the Digital Edition of Embedded Systems Design - July 2008

Embedded Systems Design - July 2008 Contents #Include Parity Bit Programming Pointers Interactive C-code Cleaning Tool Supports Multiprocessor SoC Design Building a Power Supply for Discontinuous Transmission Wireless Networks An Exception Primer Advertising Index Break Points Marketplace

Embedded Systems Design - July 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.