VHDL Issue Number:      1078
Classification:         Language Definition Problem
Language Version:       VHDL-93
Summary:                Memory leak and portability issue with TEXTIO
Related Issues:         
Relevant LRM Sections:  14.3
Key Words and Phrases:  textio, writeline, read 
Current Status:         Submitted
1076-1993 Disposition:  N/A
Disposition Rationale:  N/A
Superseded By:          N/A
-----------------------
Date Submitted:         1994/03/21
Author of Submission:   Charles Swart
Author's Affiliation:   Mentor Graphics Corporation
Author's Post Address:  8005 S.W. Boeckman Road
                        Wilsonville, OR 97070-7777
Author's Phone Number:  (503) 685-1332
Author's Fax Number:    (503) 685-1268
Author's Net Address:   chuck_swart@mentorg.com
-----------------------
Date Analyzed:          TBD
Author of Analysis:     TBD
Revision Number:        $Revision: 1.4 $
Date Last Revised:      $Date: 1995/05/15 20:07:17 $


Description of Problem
----------------------
    Here are several related problems with the writeline subprogram in
package TEXTIO.

    Consider the following (VHDL-87) source code, whose intent is to
surround a character with quotes and write those three characters to a
text file:

   procedure fwrite (variable ft: out text; c: in character) is
      variable l:  line;
      variable co: character := ''';
   begin
      write (l,co);
      write (l, c);
      write (l,co);
      writeline (ft, l);
   end;

This code contains a subtle (and unreasonable) memory leak. The basic
problem is that when the writeline is completed, the line l has a null
string as its designated value. This null string is never deallocated,
so eventually all available memory will be used up.

One possible solution to this problem points out a second problem
with writeline. The LRM describes the changes to the designated value
of l, but it does not specify whether or not l itself can be changed.
If l can be changed, then an implementation could allocate one null
array and return an access to this array whenever a writeline was
called. According to at least one ISAC member knowledgeable in this
area, this violates the intent of the LRM.

Note that in the above example, the memory leak could be removed if
the source code contained a DEALLOCATE instruction immediately
following the writeline. This solution points out a design flaw in
VHDL.  The textio package automatically allocates storage, but does
not provide a mechanism to automatically deallocate all the storage it
uses. Put another way, the source code ought to contain balancing NEW
and DISPOSE operations. Notice that the existing situation is also
inconsistent with attempts to view lines as private types, since the
explicit deallocate would be impossible if line were a private type.

A similar problem exists with read, which removes data from a
line, but never deallocates the line itself. The basic problem is the
asymmetry between readline and write, which automatically allocate
storage, and writeline and read, which do not deallocate all the
storage allocated by the other two routines.

Proposed Resolution
-------------------

One possible solution is to return a NULL value from writeline,
instead of a null array. Although technically this solution is not
upward compatible, in practice, little harm would be done. This
solution has already been implemented by at least two vendors with no
negative consequences.

A second possibility is to allow implementations to change the
value of the line parameter to the writeline procedure.

The third possibility is to make no changes, and to require an
explicit DEALLOCATE even though there was no explicit NEW.


VASG-ISAC Analysis & Rationale
------------------------------
TBD


VASG-ISAC Recommendation for IEEE Std 1076-1993
-----------------------------------------------
TBD


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
TBD