hunzip.c doesn't free its alloc'd memory

[Thakur]

Memory allocated for nodes in the provided function ReadHuffmanTree
is never free'd. Not setting a good example.

And if anyone cares, you can use mtrace() call to help you find out if
you are freeing all the memory you are allocating. More in the glibc
manual at http://www.gnu.org/manual/glibc-2.2.5/.

[L]

Post by Thakur
Memory allocated for nodes in the provided function ReadHuffmanTree
is never free'd. Not setting a good example.
And if anyone cares, you can use mtrace() call to help you find out if
you are freeing all the memory you are allocating. More in the glibc
manual at http://www.gnu.org/manual/glibc-2.2.5/.

I think they ask us to free the memory. It's under "Some Hints for
Debugging" in the lab handout where it mentions,

"Finally, as a matter of style, don't forget to free the memory that you
allocate, both for the Heap and for the Tree Nodes. "

but Yea, kinda bad, cuz we gotta find a odd place to put our freenode
function, since we cant modify the main hzip/hunzip.c file.

[Thakur]

Post by L
I think they ask us to free the memory. It's under "Some Hints for
Debugging" in the lab handout where it mentions,
"Finally, as a matter of style, don't forget to free the memory that you
allocate, both for the Heap and for the Tree Nodes. "

You are mistaken.

Notice the "you" in "don't forget to free the memory that you
allocate"? hunzip.c is allocating memory *not* huff.c or heap.c.

Also, even if you were feeling very nice and decided to free
the memory allocated by ReadHuffmanTree in hunzip.c, you can't
simply because it doesn't call any of the functions we are
supposed to write. It is in fact an error the the author's
part not something *we* need to take care of.

[Thakur]

Post by Thakur
Notice the "you" in "don't forget to free the memory that you
allocate"? hunzip.c is allocating memory *not* huff.c or heap.c.
Also, even if you were feeling very nice and decided to free
the memory allocated by ReadHuffmanTree in hunzip.c, you can't
simply because it doesn't call any of the functions we are
supposed to write. It is in fact an error the the author's
part not something *we* need to take care of.

Alas ... I am, partly wrong. It is technically possible for us to
free() nodes after we are finished with DecodeData. Although
that *really* is the job of hunzip.c, I am now trying to
decide if I should go ahead and modify my DecodeData.

I probably won't as quite frankly, the "you" argument holds
here. The handout says "don't forget to free the memory that
you allocate" and since I, as in my code, didn't allocate any
of the memory in hunzip.c, it should be none of my business to free
it. If when marking the assignment, the TAs use a custom built
hunzip.c that does indeed free the memory it allocates, the
behavior of my DecodeData would become unpredictable. I think
this is an ambiguity in the handout and I don't plan on changing
my program for this.

[L]

Post by Thakur

Post by Thakur
Notice the "you" in "don't forget to free the memory that you
allocate"? hunzip.c is allocating memory *not* huff.c or heap.c.
Also, even if you were feeling very nice and decided to free
the memory allocated by ReadHuffmanTree in hunzip.c, you can't
simply because it doesn't call any of the functions we are
supposed to write. It is in fact an error the the author's
part not something *we* need to take care of.

Alas ... I am, partly wrong. It is technically possible for us to
free() nodes after we are finished with DecodeData. Although
that *really* is the job of hunzip.c, I am now trying to
decide if I should go ahead and modify my DecodeData.
I probably won't as quite frankly, the "you" argument holds
here. The handout says "don't forget to free the memory that
you allocate" and since I, as in my code, didn't allocate any
of the memory in hunzip.c, it should be none of my business to free
it. If when marking the assignment, the TAs use a custom built
hunzip.c that does indeed free the memory it allocates, the
behavior of my DecodeData would become unpredictable. I think
this is an ambiguity in the handout and I don't plan on changing
my program for this.

Yea, I agree with you. We don't really allocate the nodes in hunzip.c. But
hey, these guys are pretty uptight about freeing memory. I just decided to
do it so I don't have to go through any hassle with the marker later on
just in case.
So yea, you got a point there, and hopefully it shouldn't be a problem
during marking.

Well, labs are over, so doesnt matter. Exam's are here. so g'luck =)