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.. > > What is the likelihood that you'd find a conflict in a library > > that's meant to compile with Mutt, or which Mutt itself requires > > to compile? Methinks pretty slim... :) > > But that's not impossible. This wouldn't be the first time a new > library takes a name already used by an application, with a possible > future dependency. Nothing is impossible, in the world of software. But I think this is so unlikely that I highly doubt it's worth worrying about. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgp2fTyiU8_qs.pgp
Description: PGP signature
