On 2016-05-03 13:02:56 -0500, Derek Martin wrote: > On Tue, May 03, 2016 at 11:11:44AM +0200, Vincent Lefevre wrote: > > On 2016-05-02 15:02:44 -0500, Derek Martin wrote: > > > The difference is the OS is using M_, and such short prefixes are > > > common for OS-level libraries. > > > > That's really the worst thing that they could do. The reason is that > > public non-OS library headers should not use reserved names (because > > they are reserved), so that the best thing they can do is to use long > > prefixes to avoid clashes between them. Thus, applications should use > > only short prefixes (for private use) in order to reduce the risk of > > clashes with these library headers (due do chains of inclusions, they > > don't always know what headers are used). And this is what they often > > do in practice. > > I don't think this makes any sense, Vincent. POSIX is littered with > such short prefixes, such as S_ for stat, O_ for open flags, etc..
Hmm... true, and this is unfortunate. :( Actually, not just short prefixes, but arbitrary macros. And the GNU libc also has its own macros. Even the usual includes #include <stdio.h> #include <stdlib.h> suffice to get some of them defined. The following command gives an idea: printf "#include <stdio.h>\n#include <stdlib.h>\n" | gcc -dM -E -xc - | sort So, I now agree that using the MUTT_ prefix may be a better idea, but it should be clear that this is reserved for Mutt and macros whose name starts with MUTT_ must not be defined by library headers. FYI, the MUTT prefix is used by some other software: claws-mail. Searching for (?-i:\bMUTT_) on https://codesearch.debian.net/ gives: #define MUTT_HOME_FILE ".muttrc" #define MUTT_TAG_ALIAS "alias" -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
