Dangerous Embedded C Coding Standard Rules (2011)

Post by angersock » Mon, Dec 30, 2013, 9:06 PM UTC

gioele wrote: post #30

kabdib wrote: post #20

Well, let's see. #1: Avoiding shifting versus doing division: Nope. Crappy compilers and bad architectures will yield bad results. Know what you're doing. #2: Use a typedef instead of a bare C type, then. Also, on many systems space is king (the last embedded system I wrote had 6 bytes left over in code space, and 16-bit operations were incredibly expensive and nearly unaffordable). #3: Just make the code clear. This…

> #1: Avoiding shifting versus doing division: Nope. Crappy compilers and bad architectures will yield bad results. Know what you're doing. Which compiler, among those still used in 2014, does not convert a division by 2 into a shift?

Post by nitrogen » Mon, Dec 30, 2013, 9:13 PM UTC

optymizer1 wrote: post #19

I'm not completely on board with #4 (initialization of variables). I agree that 'declaring and then assigning a value' _within the same block_ vs 'initialized declaration' has no speed gains, only downsides. 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 spe…

Post by nitrogen » Mon, Dec 30, 2013, 9:19 PM UTC

drivers99 wrote: post #17

theseoafs wrote: post #13

Earlier quoted context omitted.

> If you need macros to hack C to enable some functionality not inherent to the language, you should change the approach or switch to a different language. I think if you continue to do serious C hacking, you'll find a lot of places where macros are legitimately a good choice. For example, I've found that macros are very, very useful when it comes to implementing error handling in a robust way. In C, the only real wa…

The first block of code seems more readable to me than the second. I'm used to seeing the first; it's idiomatic C. I don't understand why it says "do ... while (0)" in the macro, for instance. Wouldn't you want to handle different errors in different ways anyway? In your example, you're just going to leave the file open and the string allocated? Isn't trying to influence how the compiler compiles it by using a macro…

Post by nitrogen » Mon, Dec 30, 2013, 9:24 PM UTC

anywherenotes wrote: post #23

theseoafs wrote: post #13

Earlier quoted context omitted.

> If you need macros to hack C to enable some functionality not inherent to the language, you should change the approach or switch to a different language. I think if you continue to do serious C hacking, you'll find a lot of places where macros are legitimately a good choice. For example, I've found that macros are very, very useful when it comes to implementing error handling in a robust way. In C, the only real wa…

The code I used is more like this: if ((f = open_file()) == NULL) { RETURN_ERROR(OPEN_FILE_ERROR); } if ((s == allocate_string()) == NULL) { RETURN_ERROR(ALLOCATE_STRING_ERROR); } if ... And RETURN_ERROR is defined as: #define RETURN_ERROR(my_error) { \ if (f != NULL) { fclose(f); f = NULL; } \ if (s != NULL) { free(s); s = NULL; } \ ... return (my_error); \ }

  if(failure_1) {
      goto error;
  }
  if(failure_2) {
      goto error;
  }
  
  // Do stuff
  return 0;
  
  error:
  if(f != NULL) {
      fclose(f);
  }
  if(s != NULL) {
      free(s);
  }
  return -1;