[Tcl-bugs] [ tcl-Bugs-736425 ] memory leaks in tclDate.c

[SourceForge.net <no...@so...>]

Bugs item #736425, was opened at 2003-05-12 04:27
Message generated for change (Comment added) made by hobbs
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=736425&group_id=10894

Category: 06. Time Measurement
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Joe Mistachkin (mistachkin)
Assigned to: Kevin B KENNY (kennykb)
Summary: memory leaks in tclDate.c

Initial Comment:
generic/tclDate.c

1. Shouldn't this file be using ckalloc/ckrealloc? 
2. The following variables are allocated and are 
never freed: 

int *TclDates; 
YYSTYPE *TclDatev; 

-----

It appears that we can override the use of 
malloc/realloc by defining the YYEXPAND 
preprocessor macro and having it call a function 
which does ckalloc/ckrealloc instead.

As for the leak, I think since the only memory that 
is allocated by this file is the two static variables 
above, a finalization routine is in order.  This 
should be a fairly trivial fix.

I have attached a preliminary fix for these two 
issues (this is not a patch, it's just some code to 
cut and paste into tclDate.c/tclGetDate.y).

I'm willing to learn yacc to assist if necessary.

As a "next gen" solution to this problem, I 
suggested to dkf that we parse the dates using Tcl 
code that is evaluated when necessary (since yacc 
appears to be rather wild).


----------------------------------------------------------------------

>Comment By: Jeffrey Hobbs (hobbs)
Date: 2003-05-13 16:03

Message:
Logged In: YES 
user_id=72656

No finalization is necessary because those two are statics, 
and I don't think anyone has ever changed that behavior.  The 
point is that this is all yacc, and thus we have to work with 
what yacc gives us.  It may be necessary to change the 
YYEXPAND, but I don't know of any problems that have 
arisen from this.  The "leak" is a red herring because that is a 
never-used code path.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=736425&group_id=10894