Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dangerous Embedded C Coding Standard Rules (2011)

embeddedgurus.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Dangerous Embedded C Coding Standard Rules (2011)

#21

Post by deletes »

theseoafs wrote: post #13
deletes wrote: post #2

Completely agree with no. 5. After a year with C I realized that macros are only to be used as control structures for headers and ifdefs to enable compatibility. 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. Also macros are usually used to "speed up" the code. You should never optimize before finding the real b…

> 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…

That is almost exactly like some code I have written in a project and at that time it did it's job. After revisiting the project months later after I have completely forgotten the details, I got frustrated over the macro and what did it actually do( even though I have written it ). It took me some time to track down the macro definition and convert the code in my head to understand it again. But if the code would be simple C as in your first example I wouldn't waste time on it.

Re: Dangerous Embedded C Coding Standard Rules (2011)

#22

Post by theseoafs »

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…

> The first block of code seems more readable to me than the second. I'm used to seeing the first; it's idiomatic C.

The benefits of the macro (IMO) aren't obvious from the example I gave. Like I said, I'm currently working on a personal project where macros have been the saving grace. Attaching a conditional return to every individual statement was making my code extremely hard to maintain (even for myself, who wrote it) -- wrapping common error cases in a macro made everything a whole lot simpler, and allowed me to work on my algorithms at a high level without having to run my eyes over the same error-checking `if` statements a million times.

> I don't understand why it says "do ... while (0)" in the macro, for instance.

It's normal for many macros, so that you can use them like normal statements.

> In your example, you're just going to leave the file open and the string allocated?

I sort of just made that example up off the top of my head -- you're right about the memory leak.

Re: Dangerous Embedded C Coding Standard Rules (2011)

#23

Post by anywherenotes »

theseoafs wrote: post #13
deletes wrote: post #2

Completely agree with no. 5. After a year with C I realized that macros are only to be used as control structures for headers and ifdefs to enable compatibility. 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. Also macros are usually used to "speed up" the code. You should never optimize before finding the real b…

> 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); \
  }

Re: Dangerous Embedded C Coding Standard Rules (2011)

#24

Post by deletes »

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…

Why are agreeing with OP on rule #3 and then saying it is lunatic? Did I miss something?

Quote:Better Rule: Use whatever comparison operator is easiest to read in a given situation.

One of the very best things any embedded programmer can do is to make their code as readable as possible to as broad an audience as possible.

Re: Dangerous Embedded C Coding Standard Rules (2011)

#25

Post by theseoafs »

deletes wrote: post #21
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…

That is almost exactly like some code I have written in a project and at that time it did it's job. After revisiting the project months later after I have completely forgotten the details, I got frustrated over the macro and what did it actually do( even though I have written it ). It took me some time to track down the macro definition and convert the code in my head to understand it again. But if the code would be…

You're right, the example is far too simple to warrant the introduction of a macro like this.

Re: Dangerous Embedded C Coding Standard Rules (2011)

#26

Post by ant512 »

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…

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

Re: Dangerous Embedded C Coding Standard Rules (2011)

#27

Post by theseoafs »

femngi wrote: post #16
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…

I have to strongly disagree with your example. In fact I feel it may just be one of the worst usages of macros I have seen in that you are hiding the control flow of the program and thus obfuscating your code for other programmers. It might be easier for you to read because you wrote it but for every one that comes after you it will be a massive pain that adds unneeded additional cognitive overhead. I say this from t…

To be fair, I don't see why you would have to throw your keyboard out the window. If I were debugging a source file and saw the same ASSERT macro on every other line, I would break out `grep` and track down the (extremely simple) definition so I could understand what it's doing. Moreover, returning with an error code is IMO entirely sane behavior for a macro with ASSERT in the name, especially considering halting execution of the program altogether generally isn't a good thing if you're writing a C library.

Re: Dangerous Embedded C Coding Standard Rules (2011)

#28

Post by deletes »

theseoafs wrote: post #27
femngi wrote: post #16

Earlier quoted context omitted.

I have to strongly disagree with your example. In fact I feel it may just be one of the worst usages of macros I have seen in that you are hiding the control flow of the program and thus obfuscating your code for other programmers. It might be easier for you to read because you wrote it but for every one that comes after you it will be a massive pain that adds unneeded additional cognitive overhead. I say this from t…

To be fair, I don't see why you would have to throw your keyboard out the window. If I were debugging a source file and saw the same ASSERT macro on every other line, I would break out `grep` and track down the (extremely simple) definition so I could understand what it's doing. Moreover, returning with an error code is IMO entirely sane behavior for a macro with ASSERT in the name, especially considering halting exe…

The point of assert is to check your code has values within your required parameters, so you the code is easier to debug while coding. Asserts should never be left in your code compiled for release. Even c library assert is aware of that, as it has the NDEBUG macro, which removes every assert in the code. That is also the reason why you should Never put code that might mutate your variables in them.( function calls or assigning, for example)

http://www.cplusplus.com/reference/cassert/assert/

Quote from the link: Therefore, this macro is designed to capture programming errors, not user or run-time errors, since it is generally disabled after a program exits its debugging phase.

Of course you can name your macro whatever you want, even assert, but it will confuse other developers used to c library functions.

Re: Dangerous Embedded C Coding Standard Rules (2011)

#29

Post by theseoafs »

deletes wrote: post #28
theseoafs wrote: post #27

Earlier quoted context omitted.

To be fair, I don't see why you would have to throw your keyboard out the window. If I were debugging a source file and saw the same ASSERT macro on every other line, I would break out `grep` and track down the (extremely simple) definition so I could understand what it's doing. Moreover, returning with an error code is IMO entirely sane behavior for a macro with ASSERT in the name, especially considering halting exe…

The point of assert is to check your code has values within your required parameters, so you the code is easier to debug while coding. Asserts should never be left in your code compiled for release. Even c library assert is aware of that, as it has the NDEBUG macro, which removes every assert in the code. That is also the reason why you should Never put code that might mutate your variables in them.( function calls o…

Fair enough -- assert was just the first name that came to mind. Perhaps something more descriptive like RETURN_ERROR_IF_FALSE would have been a better name.

Re: Dangerous Embedded C Coding Standard Rules (2011)

#30

Post by gioele »

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 reply on HN