predef keeps a wiki of pre-defined C and C++ compiler macros

The problem predef solves is knowing which macro means what

C and C++ compilers automatically define certain macros, and the README describes exactly what those macros are for: they can be used to check for compiler or operating system features, which is useful when writing portable software. The predef wiki exists so that you can look up what those names are instead of guessing.

The scope is broader than compiler names. The pages list pre-defined macros that can be used to identify standards, compilers, operating systems, hardware architectures, and even basic run-time libraries at compile-time. That last category is the one that catches people out. Whether a given runtime library defines a particular macro is a property of the library build, not of the compiler, and the wiki records it as such in a separate file.

Who reads it is fairly specific: developers writing conditional compilation, library authors supporting several compilers, and anyone porting code to a platform they do not own. It is not aimed at application developers who never use #if. The repository language is listed as unknown, which fits a project made of Markdown files rather than code, and the topics confirm the intent with c, documentation, ifdef and portability.

The value is in the mapping. The macro names are scattered across vendor documentation, and a name such as a version number macro can be spelled differently on every toolchain. Having one place that says which macro means which compiler, and which value corresponds to which release, removes a category of debugging that is otherwise very hard to see.

Eight Markdown files split into indices and guidelines

The repository is small and entirely made of Markdown. The ten top-level files are README.md, LICENSE, DataModels.md, Endianness.md, FeatureMacros.md, VersionNormalization.md, Architectures.md, Compilers.md, Libraries.md, OperatingSystems.md and Standards.md. There is no source directory, no build script and no test suite, because there is nothing to compile.

The README splits the content into two kinds of page. The first group is where the macros live: Standards, Compilers, Libraries, Operating systems and Architectures. The second group holds general guidelines: Version normalization, Feature macros and Endianness. DataModels.md appears in the repository listing as well, sitting alongside the other reference pages.

The guideline pages are the more interesting part for practice. Version normalization in particular matters because vendors encode versions in incompatible ways, some as a single integer, some as a date, some as a number that has to be divided to get a meaningful value. The page exists to tell you how to compare those values correctly, which is exactly the arithmetic that people get wrong when they write a version check by eye.

The split also tells you where to look for a given fact, which is the main way you will use this project. A compiler identification macro lives in Compilers.md, an operating system macro in OperatingSystems.md, and the rules for interpreting a version number in VersionNormalization.md. Each page is a table, and each entry maps a macro to what it means.

Two worked examples of using the macros in a #if

The README illustrates the intended use with two small C examples, and they are worth reading closely because they show the two different jobs a macro check can do.

The first checks for language capability rather than for a product. If you want a generic or opaque pointer type, you would use void pointers, except that ancient K and R compilers from before the first ANSI C standard do not support them, so the code defines its own type instead:

#if defined(__STDC__) || defined(__cplusplus) || defined(_MSC_EXTENSIONS)
typedef void * t_pointer;
#else
typedef char * t_pointer;
#endif

The second is a version check. Microsoft Visual C++ version 4.2 added a pragma to reduce compilation times by only including a file once, and the guard tests the version macro before using it:

#if defined(_MSC_VER) && (_MSC_VER >= 1020)
#pragma once
#endif

The README notes the reason for the defined() wrapper around _MSC_VER, namely that if the macro is not defined it evaluates to zero, however some compilers may complain about an undefined macro. That is a small detail, but it is the kind of detail that the wiki exists to record.

The pattern in both cases is the same: test a macro that identifies a toolchain or a standard, and fall back to something older. Neither example needs predef at compile time. What the wiki supplies is the list of which macros to test and what their values mean, so that your own fallback logic is written against verified names.

Where the macro data comes from and why it can be wrong

The README states the provenance plainly: the macros contained in these pages have been obtained through vendor documentation, the defines script, contributors, and third-party source code. The defines script is hosted on the project's SourceForge site, and the contributors are named in a long list that includes people known for work on portability and build systems.

The same paragraph carries the disclaimer that matters most: no guarantee about the correctness of the macros is given. Read that as the defining constraint of the project. It is a community-maintained reference, not an authoritative specification, and a macro that is wrong there will be wrong in your code with no warning at compile time.

There is a second structural weakness that follows from the format. The knowledge is in prose and tables, so a compiler change, a new vendor macro or a revised version encoding arrives as an edit to a Markdown file rather than as a versioned, machine-readable dataset you can depend on programmatically. There is no schema and no CI check against a compiler's own -dM output.

For most uses that is acceptable, because the reader is a human deciding what to put in a #if. It stops being acceptable the moment you want to generate code from the list, and it means the wiki should always be the second opinion after checking the values your actual toolchain reports.

How predef differs from Autoconf and the build tools

The README names Autoconf as an often-used alternative and is fair about the difference. Autoconf is a more powerful tool to examine various types of features, including compilation options, but it is fairly Unix-centric and requires a Unix layer on other platforms, with Cygwin on Windows given as the example. Autoconf probes by compiling and running test programs, so it answers questions about your build environment, on your machine, at build time.

predef answers a different question. It tells you what names exist and what they mean, without running anything. That makes it the right tool when you cannot execute a probe, for instance when you are writing a header that a compiler on another platform will parse, or when you are trying to understand an unfamiliar third-party source tree that already contains thousands of #ifdef branches. It is also the cheaper answer when you only need to know which macro identifies a compiler, not what a feature test compiles to.

The README lists a longer set of alternatives too: Buildtool, CMake, SCons, PMK, Jam, Ant and Bakefile. These sit in the same family as Autoconf, in that they configure a build by inspecting the environment. predef sits outside that family entirely, which is why it is best described as documentation with a licence rather than as a build tool.

Maintenance, licence and how corrections reach the wiki

The repository is not archived, and the last push was on 2026-06-23. There are no GitHub releases, so the project has no tagged versions to pin, and the only stable identifier for a given state of the wiki is the commit on the default branch, which is master. The contributor list is long and includes repeated contributions from some of the same names, which is a fair sign of a project sustained by individual patches rather than a release process.

Corrections have two documented routes. The README asks for updates and corrections to be sent to the predef-contribute mailing list, hosted on lists.sourceforge.net, or to be submitted as pull requests on GitHub. Pull requests are the better route if you can format a diff against the relevant Markdown page, since the pages are structured tables and an edit lands in the right place.

The licence is CC-BY-4.0, which is a content licence rather than a software licence, and that is the right choice for a wiki of facts. The practical implication is attribution: if you reproduce a table of macros or a passage of the guidelines in your own documentation, you need to credit the source. The two C snippets in the README are short functional examples rather than expressive prose, but the pages they come from are attributed content, so a project that copies substantial parts of the wiki should carry a credit line. Whether a given reuse meets the attribution requirement is a question for your own review rather than something this article can settle.

Editorial conclusion

Adopt predef as a reference when you are writing conditional compilation for a platform you cannot test, especially when the alternative is trusting a snippet copied from an old forum post. Do not adopt it as a detection mechanism, since it is prose and tables that a human reads, not something a build script consumes, and it will not tell you whether a macro is defined on the compiler in front of you. Verify first by checking the compiler and version macros in the list against the values your own toolchain reports, since the pages state that no guarantee about the correctness of the macros is given, and note that the last push was on 2026-06-23 with no tagged releases, so corrections arrive as commits to the master branch rather than as versions you can pin.

Frequently asked questions

Official sources

1. cpredef/predef on GitHub
2. Issues
3. License: CC-BY-4.0
4. README