[Scummvm-devel] remove macro conflict in system headers

[Johannes Schickel]

In fact, I'm not sure about this whole issue. I think plain C allows
standard library functions to be defined as macros. I wonder how C++
handles this... i.e. is the name disallowed then? Should the compiler tread
it specially?

At any rate, a workaround for compilation would be to use the following:

class A {
public:
        void (remove)(const char *);
};

void (A::remove)(const char *) {
}

i.e. use parenthesis around the remove use (this is somewhat suggested in
the C standard when you declare library functions on your own or take their
address IIRC).

// Johannes


On Thu, Oct 31, 2013 at 2:26 PM, Willem Jan Palenstijn <wjp at usecode.org>wrote:

> On Thu, Oct 31, 2013 at 02:21:56PM +0100, Johannes Schickel wrote:
> > On Thu, Oct 31, 2013 at 1:55 PM, Willem Jan Palenstijn <wjp at usecode.org
> >wrote:
> >
> > > On Thu, Oct 31, 2013 at 12:35:28AM +0400, Икар wrote:
> > > >
> > > > When I building Tsage engine for symbian with GCCE 4.4.1 I got many
> > > erros "macro `remove' used without args" because compilers think what
> > > function :
> > > > virtual void remove()=0
> > > > and his virtual inheritance comes from macro definition
> > > > #define remove(x) unlink(x)
> > > > This define placed in sys/unistd.h
> > > >
> > > >  I try to  use '#undef remove' in core.h but it doesn't work.
> > >
> > > What do you mean by "doesn't work"?
> > >
> > > We use remove() in more places than just core.h, so I'm not sure what
> you
> > > tried or how it doesn't work...
> > >
> >
> > I think he talks about
> >
> https://github.com/scummvm/scummvm/commit08cd61acc249f93c2760fc45b45705c8836fbc7bwhich
> > was reverted later. One possibly issue here could've been that you
> > undefine such macros by simple "#undef remove" instead of "#undef
> > remove(x)". Other issues might include core.h wasn't included in the
> > offending files, core.h was included first and then #undef remove was
> > before the actual #define.
>
> The #undefine was at the very top of the header, so that does not sound
> like a
> very safe or robust way to undefine something defined in a system header.
> It
> doesn't surprise me at all that it doesn't compile after just thar one
> change.
>
> -Willem Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20131031/0677d527/attachment.html>