@Munk(4):
First, welcome!

What you say about the times that there’s no all-correct way to write a macro is absolutely correct. That’s why I suggest inline functions, or inline function templates.

The BLOCK_SET macro is written for plain C? As I understand, C99 now supports inline functions. Were you worried about performance that you implemented this as a macro? I guess you were reluctant to use a function because then you had to pass the first three arguments as pointers and add a level of indirection. Am I correct? Wouldn’t the optimizer realize the reason for the pointers (persistence of changes as opposed to real pointer semantics) and optimize the overhead away? Have you actually tried this and inspected the assembly code? (Of course, it’s too much work most of the time.)
I’m curious because my experience with plain C is really really limited. So I grab every opportunity not to lose touch!

But, any of the OOP problems can be solved easily with wrapping, which should be done anyways…in example, a macro from the project I am working on right now(in c)

#define BLOCK_SET(CODEV,MAINV,HEADV,VALUE) \
{ \
if( SYS_STATE.MODE == CODE ) \
CODEV=VALUE; \
else if(SYS_STATE.MODE == EXPRESSION ) \
MAINV = VALUE; \
else if( SYS_STATE.MODE == EXPRESSION ) \
HEADV=VALUE; \
}

The thing you need to remember that writing tons of macros will require lisp-like paren usage

#define SAFE_DELETE(ptr)  delete (ptr), (ptr) = 0

// Case 0
x = SAFE_DELETE(p);
/*  The above causes a compile error to be generated (as might be expected)
 * because the return type of "delete" is "void", but we are encountering a
 * case of "Operator Mishaps From Hell", because the assignment operator
 * precedes the comma, we are not taking the return value of the whole
 * macro, but only of a part of it. We are lucky that the return value of
 * "delete" is "void", since it generates a compile error almost all the time.
 */

// Case 1
x = y = SAFE_DELETE(s);
x = (y = SAFE_DELETE(s));
// These won't compile, but think what would happen if they did!

// Case 2
for ( ; SAFE_DELETE(s); );
/*  This one _will_ compile with not even a warning at normal warning
 * levels. I don't think anyone would do this, not with this macro,
 * but can we say that for all such macros?
 * We need to enclose the macro in parentheses, to make its behavior
 * consistent, don't we?
 */

// Case 3
#define SAFE_DELETE(ptr)  (delete (ptr), (ptr) = 0)

x = SAFE_DELETE(s);
for ( ; SAFE_DELETE(s); );
/*  Now, the above compile and work consistently, but their behavior
 * is no longer consistent with the "delete" operator, which
 * is supposed to return "void", not a pointer.
 * I must admit though, that this is a very small problem and can
 * be over-looked. After all, we have changed the name of our macro
 * and no one should expect it to behave exactly as "delete".
 */