[ecma]

This isn't wrong but I've got issues with some of the examples, especially the lack of a solution for #2 and #4.

#2 is referred to as an unsafe macro because of the multiple evaluation of its arguments. In some cases this is fine but it may need to be documented that the macro is unsafe for future users. It is also entirely possible to convert these macros into safe ones if you're willing/able to use GNU C extensions like typeof. The SEI CERT secure C wiki has a good reference for this at [0].

#3 presumes you want to compose functions but I'd suggest that by doing so you are writing bad C. Because of the lack of any type of side-band error reporting (exceptions etc) you must presume that your functions will always return a sane/non-error value. That's not a good assumption even for your own code and definitely not for the C library or any other libs. In addition, this is just another unsafe macro which could be made safe as above.

#4 doesn't explain the solution to the problem it poses which is annoying because it's the most important one IMO. There are a number of ways to make a multi-line macro safe for use in an unbraced expression body. My preferred way is to define the macro with a always false-post check while loop. e.g.

    #define MY_NAME_JEF(x) do{ \
        const char jef[] = "jef"; \
        printf("my name %s, not %s\n", jef, x); \
    }while(0)

Note the lack of a trailing semi-colon. This is because we expect the macro to be terminated with its own semi-colon. Stupid example but it gets the point across I suppose.

Check out the secure C wiki, it's full of gems which can help you avoid issues with macros, and much more.

[0] https://wiki.sei.cmu.edu/confluence/display/c/PRE31-C.+Avoid...

[Stratoscope]

> #2 is referred to as an unsafe macro because of the multiple evaluation of its arguments. In some cases this is fine but it may need to be documented that the macro is unsafe for future users.

In the early days of C programming, a naming convention was adopted to warn about this. If you wrote a macro that might have multiple evaluation of its arguments, you named it in UPPERCASE as a warning:

    #define MIN( a, b )  ( (a) < (b) ? (a) : (b) )

This practice spread into pretty much all macro definitions. If you defined a macro of any sort, you gave it an uppercase name, even if the macro didn't take any arguments at all and therefore warning about multiple evaluation was moot:

    #define MAX_SIGNED_SHORT 32767

From there the notion spread into other languages that all constants ought to have UPPER_CASE_NAMES. So this is why you see JavaScript code like:

    const TEMP_ITEM_LIMIT = 100;

instead of something easier on the eyes like:

    const tempItemLimit = 100;

[photonios]

Although I get that the original intent was different. I actually find making all constants uppercase a useful practice. When reading the code, it's easy to see what is a local variable and what is not, or at least not supposed to be.

[felipelemos]

I really find TEMP_ITEM_LIMIT easier to read than tempItemLimit.