bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bison'd files don't compile under Microsoft VC++


From: Paul Eggert
Subject: Re: bison'd files don't compile under Microsoft VC++
Date: Thu, 14 Feb 2002 11:26:40 -0800 (PST)

> From: "David Gluss" <address@hidden>
> Date: Thu, 14 Feb 2002 09:18:52 -0800
> 
> I'm not begging you to go support MS in a new product...
> I just wish you guys hadn't broken an existing working one.

We may have some wires crossed here.  I'd just like to clarify the
issue, if it's not clear already.

The patch that I proposed yesterday (and plan to install) should cause
Bison to start working again with your Microsoft C++ compiler.

The drawback of the patch is that it pollutes the namespace of a C++
parser, in precisely the same way that it pollutes the namespace of a
C parser.  For example, if you are compiling on a non-GNU host, you
won't be able to use the identifier `abort' at the top level, because
your parser will include <stdlib.h> and this declares `abort'.  This
problem is unavoidable in C, but the patch will cause the problem also
to occur in C++.

(By default this namespace pollution doesn't occur on GNU hosts, even
for C code, since the parsers use special hooks in that case.  But the
hooks are not portable, and on non-GNU hosts portable code has no
choice but to include <stdlib.h> if it wants to use malloc and free.)

People who write C parsers have long been used to namespace pollution
like this, so it's not too much of a problem in practice for C.  In
practice, C code simply avoids identifiers like `abort'.

However, one of the goals of the C++ community has been to avoid
namespace pollution, and for the past several weeks we have been
trying to accomplish this goal with Bison-generated C parsers.  There
are other serious C++-related problems with these parsers, so this was
merely a nicety: true support for C++ will require a new approach,
which is being worked on.

Unfortunately, this nicety is proving to be a portability problem, as
you found with Bison 1.33 and the Microsoft compiler.  Since it is
just a small, temporary advantage, and since it is causing porting
problems, we will stop trying to support it in the C parser, and wait
until the true C++ support is available before trying to address this
issue.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]