Against own preprocessor flags

[KarlisRepsons]

Hi there,
I was reading one person's 10 tips for portable C code [1] and the fourth states:

Use Only Built In #ifdef Compiler Flags, Do Not Invent Your Own

I guess he is making up by writing "If you do need to implement something platform specific, wrap it in the 100 percent STANDARD #ifdefs.", because, to begin with, how about autotools tests?

Your opinion on how much can we avoid making new compiler flags? Have there been any efforts to standardize the flag names between FLOSS packages, which often use autotools tests?

[1] http://www.ski-epic.com/source_code_essays/ten_rules_for_writing_cross_platform_c_source_code.html

[kbw]

I understand him to mean, use standard macros for the native environments. I agree.

This would cover any build package.

This problem he's addressing is, the standard defines NDEBUG for a release build (for assert support). Or 32bit Windows defines _WIN32. But in Visual Studio for example, you'll see DEBUG and WIN32 defined for wizard generated projects.

This leaves us wondering, should we use NDEBUG or DEBUG, _WIN32 or WIN32. It's get's better with _UNICODE or UNICODE, and so on.

If you make up your own, you just add to the confusion.

[KarlisRepsons]

I was wrong in writing "compiler flags", actually "preprocessor flags" might be better.

Well, but about FLOSS packages and autotools tests? Don't they introduce quite a few such flags? Can it be avoided or somewhat standardized?