Re: Bison 1.50 experiences

[Hans Aberg]

At 00:45 -0700 2002/10/14, Paul Eggert wrote:
>> - 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 am using a system that automatically is searching all subdirectories. So
it would normally not be a problem on UNIX computers.

But the C/C++ compiler is fully integrated, so the header bitset.h (the one
is a   compatibility header to C++ standard <bitset>) in effect became a
part of the combined C/C++ library. Strictly speaking, the C++ standard
does not require any such bitset.h compatibility header, though.

I am not sure it's worth for you to do anything about it -- just keep it in
mind if somebody else gets the problem.

>> - 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.

Bison creates a temporary file that is handed over as argument to M4. Then
M4 pipes back its output. The temporary file is then unlinked, unless one
is asking for it to remain by some tracing options.

For this temporary file, created in output_skeleton() in output.s, I used:

static void
output_skeleton (void)
{
  /* Store the definition of all the muscles. */
  const char *tempdir = getenv ("TMPDIR");
  char *tempfile = NULL;
  FILE *out = NULL;
  int fd;

  tempfile = stringappend(short_base_name, ".m4");
  ...
Even if it by some mistake it remains, the name is wellknown.

I need a second temrrary file when I am not using pipes from M4 output to
Bison. Then, in m4_invoke, I used
  stringappend(short_base_name, ".m4.out");

>> 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.

This is hard to achieve: M4 does not even close some files properly, it seems.

This becomes problem when M4 is used as a library, and not as a program,
because the files open from an earlier run may be locked for use in another
run.

>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.

If you want to do it that way, I guess you have to program it some:
Standard C has to ways of creating temporary files, unnamed by tmpfile(),
and a way to created new file names using tmpnam(). In the latter case,
clearly the file will behave as any other file, unless you explicitly
unlink it.

>> 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!")

Well, that probably depends on the compiler. Has that happened recently? --
I mean, nowa most files and memory is buffered (the latter by paging), so
that the clear distinction between the two becomes fuzzy.

>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.

I mentioned those things because Akim said he wanted to integrate Bison &
M4 fully. So now you have some inputs on that.

  Hans Aberg