野牛-符号表-Malloc免费匹配

Question

I am going through mfcalc example in the Bison manual and I had a question about the symbol table.

Specifically in the routine putsym() we have calls to malloc but I don't see the corresponding call to free . Do we need to deallocate symbol table ( sym_table in the following code) manually or does the tool take care of this automatically?

symrec *
putsym (char const *sym_name, int sym_type)
{
  symrec *ptr = (symrec *) malloc (sizeof (symrec));
  ptr->name = (char *) malloc (strlen (sym_name) + 1);
  strcpy (ptr->name,sym_name);
  ptr->type = sym_type;
  ptr->value.var = 0; /* Set value to 0 even if fctn.  */
  ptr->next = (struct symrec *)sym_table;
  sym_table = ptr;
  return ptr;
}

Answer 1

"The tool" knows nothing about what your actions do.

I quoted "the tool" because in reality, there are at least two code generation tools involved in most parsing projects: a parser generators (bison, in this case) and a scanner generator ((f)lex, perhaps). The mfcalc example uses a hand-built lexer to avoid depending on lex although it would probably have been simpler to have used (f)lex. In any event, the only calls to the symbol table library are in the scanner and have absolutely nothing to do with the bison-generated code.

Of course, there are other tools at play. For example, the entire project is built with a C compiler and runs inside some kind of hosted environment (to use the words of the C standard); in other words, an operating system and runtime support library which includes implementations of malloc and free (although, as you point out, free is nowhere called by the example code).

I mention these last because they are relevant to your question. When a process terminates, all process resources are released, including its memory image. (This is not required by the C standard but almost all hosted environments work that way.) So you don't really need to free() memory allocated if it is going to be in use up to program termination.

Like global variables, unreleased memory allocations were pretty common at one time. These days, such things are considered poor practice (at best) and most programmers will avoid them, but it wasn't always the case. There was a time when many programmers considered it wasteful to track resources only in order to release them just before program termination, or to jump through the hoops necessary to ensure that pre-termination cleanup was guaranteed to execute. (Even today, many programmers will just insert a call to exit(1) when an unrecoverable error occurs, rather than going to the bother of tracking down and manually freeing every allocated memory block. Particularly in non-production code.)

Whether you approve of this coding style or not, the examples in the bison manual (and many other code examples of all kinds) date back to that innocent time.

So, it's true that the symbol table entries in this example are never freed. Your production code should probably do better, but it also should probably use a more efficient data structure and avoid depending on a (single) global context. But none of that has anything to do with the bison features that mfcalc is attempting to illustrate.