Re:Dangerous Embedded C Coding Standard Rules (2011)
by ant512 on Monday December 30, 2013 @02:32PM
(#6986350)
I'd suggest that, if a variable with an undefined value is a valid state for the program, the declaration is in the wrong place. How about this alternative?
int dec(int a, int condition) {
if (condition) {
int temp = 0;
//compute something here in a loop
while (temp < a) {
a -= (temp++);
}
}
return a;
}
Re:Dangerous Embedded C Coding Standard Rules (2011)
by optymizer1 on Monday December 30, 2013 @11:08PM
(#6988897)
That's the obvious next step, but it's not valid C89 and that may or may not be relevant for people doing embedded programming. Personally, I'm all for using newer standards and declaring variables locally when it makes sense. Sometimes I like to see all variables at the top of the function though.
Re:Dangerous Embedded C Coding Standard Rules (2011)
by nitrogen on Monday December 30, 2013 @04:13PM
(#6986997)
I'm not particularly familiar with x86-64 calling conventions. Where is the code that sets up the stack frame? Would this code look different if temp were created inside the if() block, not just initialized there?
Re:Dangerous Embedded C Coding Standard Rules (2011)
by optymizer1 on Monday December 30, 2013 @11:23PM
(#6988931)
In C, variables have function-level storage. I don't recall the actual term from the C standard, but the storage for _all_ variables declared in any blocks inside a function is allocated at the beginning of the function, when the stack frame is set up. So there is 'no way' to create 'temp' only inside the if block.
Re:Dangerous Embedded C Coding Standard Rules (2011)
by nitrogen on Tuesday December 31, 2013 @12:03AM
(#6989076)
Okay. I knew variables had block-level scope. I've read some of the ISO C standard, but hadn't caught the part where variables have function-level storage. I was wondering because, years ago, I read some disassembled code that did lots of stack allocations in the middle of functions, and not just for the purpose of calling another function.
Can you point to a reference showing that variables have function-level storage? The closest I can find in the C standard draft I'm looking at is 6.2.4.6, which suggests block-level lifetimes for variables: "For such an object that does not have a variable length array type, its lifetime extends from entry into the block with which it is associated until execution of that block ends in any way."
However, if the assignment can happen in a _different block_ (maybe inside an 'if' block) you could save 1 memory write, depending on how many times the if condition is satisfied.
This obviously optimizes for speed at the expense of maintainability, and it's for the programmer to make intelligent trade offs, but the fact is that one method is faster than the other.
Silly example that decrements 'a' repeatedly if condition is non-zero:
We can disassemble the output to verify that dec() will only write to memory if the condition was satisfied (see 400458), while dec2() will always write into temp (see 400482): The above code was compiled with gcc 4.1.2 on amd64/linux. gcc -O2 and gcc -O3 completely do away with the 'temp' variable and generate fewer instructions.