Re: Bison 1.50 experiences

[Paul Eggert]

> From: Hans Aberg <address@hidden>
> Date: Sun, 13 Oct 2002 19:42:43 +0200
> 
> - I had a problem with the library header bitset.h because there is a C++
> header <bitset>, and on my system there was also a <bitset.h> compatibility
> header.

Why was this a problem for Bison?  It should have been built with an
-I option that caused your compiler to use Bison's bitset.h, not the
compatibility header.

> - I think that one should try to strive for a Bison which does not rely on
> temporary files, which tend to litter the directories after use (especially
> if the program terminates abnormally or is used as a DLL).

I'm not sure why Bison needs temporary files now -- perhaps Akim can
chime in on that.  But if it needs them, it definitely must clean them
up if interrupted, so code to do that must be added if the need for
temporary files cannot be removed.

> One way to avoid temporary files littering the directory is to make the
> names of them explicit

That doesn't solve the problem in question, since they still need to
be cleaned up if interrupted.

Historically, temporary files (e.g. used for compilers, which are like
Bison in many ways) are stuck in some other directory.  There are pros
and cons of /tmp, but I suspect Bison should just join the throng here
rather than innovate.


> Also note that there are Std C facilities for creating temporary files:

In practice the mkstemp facility used by Bison tends to work better.
The Std C facility, for example, creates an unnamed file, which can be
a bear to manage if Bison writes a lot of data to that file.  ("My
disk space is exhausted but there aren't any files there!")

As far as making Bison a DLL or integrating with M4 goes, that might
be a nice thing but right now I want to concentrate on getting the
current version reliable and portable.