[Samba4] [FreeBSD] Conflicting definition of MACHINE macro
Jelmer Vernooij
jelmer at samba.org
Mon Oct 8 13:08:29 GMT 2007
On Mon, Oct 08, 2007 at 01:45:15PM +0200, Timur I. Bakeyev wrote:
> On Mon, Oct 08, 2007 at 12:03:31PM +0200, Jelmer Vernooij wrote:
> > Am Montag, den 08.10.2007, 04:44 +0200 schrieb Timur I. Bakeyev:
> > > Here is another problem. Compilation of the policy subsystem fails due
> > > to the conflict of the system-wide definition of the MACHINE macro and
> > > local MACHINE macro in the lib/policy/lex.l. In the recent SVN versions
> > > this was fixed by renaming macro into CLASS_MACHINE, but usage of the
> > > simple name macros like CLASS, DEFAULT, etc. is asking for troubles, as
> > > these names are too common and may be used somewhere else. The best
> > > practice here is to give more application specific names to the macros,
> > > let's say prepend them with the POL_ prefix in this case.
> > I'm not convinced this is necessary. These are enum values (basically
> > defines), so they don't clutter the global symbol namespace. All they
> > can conflict with are defines in the system headers and that doesn't
> > appear to be a problem at the moment.
> Oh, they DO! How did I find this out, you think? Local MACHINE definition
> was conflicting with the <machine/param.h> which has:
> #ifndef MACHINE
> #define MACHINE "i386"
> #endif
This one has already been fixed.
> Now MACHINE and USER are prepended with CLASS_ to work around this problem,
> but I think it's safer to use local name space just to be on a safe side.
I don't want to clutter the code by prefixing everything unless we can
avoid it. These defines are only used in this particular C file, which
only includes system headers. We can easily spot duplicate defines in
the build farm.
There are lots of other defines or private function names in Samba that
could /potentially/ clash with system headers they include, but I'd
rather not prefix all of those with SAMBA_ either just to be sure.
Public symbols/defines are a different story, as they can be a problem
for users of Samba libraries.
Cheers,
Jelmer
More information about the samba-technical
mailing list