freeing allocated memory

[Curley Q.]

for(;
{
c = a * b;
c %= 100000;
printf("%9d", c);
d = int2str(c);
left = midstr(d, 0, 3);
right = midstr(d, strlen(d)-3, 3);
free(d);
a = atoi(left);
b = atoi(right);
if(a * b == 0)
break;
printf("%6d %6d\n", a, b);
}
free(left);
free(right);

In the code fragment above d is a buffer allocated by a call to
malloc in int2str and freed each pass through the loop. left and
right are also buffers allocated by calls to malloc in midstr,
but they are freed only once when execution breaks out of the
loop. What happens to the memory that is allocated to left and
right in each call to midstr? Is allocated memory getting cleaned
up properly in this code?

 

[Christopher Benson-Manica]

In the code fragment above d is a buffer allocated by a call to
malloc in int2str and freed each pass through the loop. left and
right are also buffers allocated by calls to malloc in midstr,
but they are freed only once when execution breaks out of the
loop. What happens to the memory that is allocated to left and
right in each call to midstr? Is allocated memory getting cleaned
up properly in this code?

This sounds very homework-like, so I'll just tell you that the
answers are "bad things" and "hell no", respectively.

 

[Curley Q.]

This sounds very homework-like, so I'll just tell you that the
answers are "bad things" and "hell no", respectively.

Not homework. They only teach VisualBasic and Java in my school.
Your answer to question #2 was OK, but maybe somebody could do a
better job with #1.

 

[Christopher Benson-Manica]

for(;
{
c = a * b;
c %= 100000;
printf("%9d", c);
d = int2str(c);

What if malloc() fails (returns NULL)? Are you handling that
(unlikely) occurrence?

left = midstr(d, 0, 3);

Whatever memory left pointed to before is lost forever; you'll never
be able to free it. Same for the line below. Call free beforehand,
though, and all is well.

free( right );

right = midstr(d, strlen(d)-3, 3);

What if left and right are NULL? You should check.

free(d);
a = atoi(left);
b = atoi(right);
if(a * b == 0)
break;
printf("%6d %6d\n", a, b);
}
free(left);
free(right);

All the memory you lost track of (and didn't free) is presumably
returned to the operating system once your program exits, but you
should manage it judiciously yourself.

What happens to the memory that is allocated to left and
right in each call to midstr?

It stays allocated, and with no pointer to it, you can't free it.

Is allocated memory getting cleaned
up properly in this code?

No; see above.

I'm sorry to hear they don't teach C at your school - the tragedy
continues, apparently.

 

[Curley Q.]

All the memory you lost track of (and didn't free) is presumably
returned to the operating system once your program exits, but you
should manage it judiciously yourself.




It stays allocated, and with no pointer to it, you can't free it.

Thanks, that's what I wanted to know.

I'm sorry to hear they don't teach C at your school - the tragedy
continues, apparently.

A member of the faculty told me C was "obsolete." I guess I'm
just old-fashioned.

Cheers,
CQ

 

[Stephen Sprunk]

A member of the faculty told me C was "obsolete." I guess I'm
just old-fashioned.

Sounds like your faculty is obsolete as well, but IMHO that's rather common.

Every tool has a use; C is useful for many things Java and VB can't do --
for instance, writing VB and Java interpreters and the OSes they run on.

S

 

[August Derleth]

Thanks, that's what I wanted to know.

BTW, this is what people call a 'memory leak'.

(Admittedly, people throw in some other qualifiers as well, but this isn't
an X-rated newsgroup. )

A member of the faculty told me C was "obsolete." I guess I'm
just old-fashioned.

That member of the faculty is broken and needs to be fixed. (Er, repaired.)

C is still the language of choice for many, many things. OS design, for
example, is 90% C and 10% machine-specific assembly. (Well, percentages
vary, but that's becoming a common ratio.) This means that the OS's
structure is portable between machines, so you can run the same OS on your
Cray supercomputer, your System/360 legacy system, and your embedded
controllers. See NetBSD for an example of this philosophy.

Embedded systems are usually programmed in something besides pure assembly
these days, too, and you can do a lot worse than C. (You can use BASIC,
for example. ) C's standards impose as little on the compiler writers as
possible, and the C virtual machine is largely compatible in philosophy
with most hardware machines. (Yes, C has a virtual machine, it simply
usually isn't explicitly implemented other than via libraries. C provides
a flat, indefinite-length memory model, good support for floating-point
numbers, and the ability to address chars at arbitrary memory locations
within an array. Some systems have to go through contortions to meet these
demands, but many of them fit this model quite naturally.)

 

[Sam Dennis]

C provides a flat, indefinite-length memory model

Locally flat, please.