On Mon, 10 Dec 2012, David Young wrote:
What do people think about setting stricter guidelines for using the C preprocessor than the guidelines from the past?
Maybe.
The C preprocessor MUST NOT be used for 1 In-line code: 'static inline' subroutines are virtually always better than macros.
I disagree with this one. If you tone it down to "SHOULD NOT" or "prefer static inline functions where appropriate" then I might agree, but MUST NOT is way too strict. Sometimes the C standard mandates the use of macros, and I would not want to violate that simply to comply with your "MUST NOT" requirement.
For example, the ctype(3) API must be provided by extern functions, and may also be provided by macros; I don't see how the macros could be replaced by static inline functions without breaking something. The first breakage that springs to mind is that adding parentheses around a name like (isalpha) is supposed to prevent it from being interpreted as a macro, so you get the function instead; but there's no analogous way to prevent something from being interpreted as a static inline function so you get the external function instead.
2 Configuration management: use the compiler & linker to a greater extent than the C preprocessor to configure your program for your execution environment, your chosen compilation options, et cetera.
Again here, MUST NOT is way too strict. While I don't like *.c files littered with ifdefs, I think it's OK for *.c files to contain many macro invocations, and it's OK for header files to contain many ifdefs, but both these would be outlawed by your "MUST NOT" requirement.
--apb (Alan Barrett)