| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 95:36:03 |
| Calls: | 290 |
| Files: | 904 |
| Messages: | 76,423 |
Is there a memory leak? What it sounds strange to me is that Valgrind reports: "total heap usage: 9 allocs, 8 frees, …" when for me the calls to "malloc" should be 8, not 9.
void add_element( unsigned int i )
{
DIGIT *p;
/* If the first element (the head) has not been
* created, create it now.
*/
if ( head == NULL )
{
head = last = (DIGIT *) malloc( sizeof ( DIGIT ) );
head->dgt = last->dgt = i;
head->next = head->prev = last->next = last->prev = NULL;
return;
}
/* Otherwise, find the last element in the list */
for (p = head; p->next != NULL; p = p->next)
; /* null statement */
next = (DIGIT *) malloc( sizeof ( DIGIT ) );last = p->next;
next->prev = p;
next->dgt = i;
next->next = NULL;
}
void dealloc()
{
for ( const DIGIT *p = head; p->next != NULL; p = p->next )
if ( p->prev != NULL )
free( p->prev );
free( last );
}
void dealloc()
{
for ( const DIGIT *p = head; p->next != NULL; p = p->next )
if ( p->prev != NULL )
free( p->prev );
free( last );
}
I think you might have an off-by-one error in this function. You stop
the for loop when p->next == NULL, which means you never enter the body during the time when p == last. Which means you never free the second-to-last element in the list.
It is p->prev not p->next, by doing so free() don't apply for the "last" element so I've to free apart
Given a list of 5 items, you will free items 1, 2, 3 (during the loop)
and 5 (after the loop), but not 4.
OK I'll try some test removing the "if statement"
for ( const DIGIT *p = head; p->next != NULL; p = p->next )
next == NULL at that point, and the for loop stops. So [4] isnot freed.
I'm doing the exercises of a C language handbook.
Put in something to count the number of calls to malloc() and free()
respectively. Don't forget calls outside of loops.
There isn't calls to malloc() or free() outside loops. What do you mean?
From a quick re-glance through your code...
head = last = (DIGIT *) malloc( sizeof ( DIGIT ) );head->dgt = last->dgt = i;
p->next = (DIGIT *) malloc( sizeof ( DIGIT ) );
free( last );
I'd prefer a mailing-list instead, once finished all the exercises, I'd
like to looking for somebody that he has my same handbook and to ask him
for exchange the exercises for comparison purpose.
Does anybody know a mailing-list for C language questions?
I'd prefer a mailing-list instead, once finished all the exercises,
I'd like to looking for somebody that he has my same handbook and to
ask him for exchange the exercises for comparison purpose.
I would rewrite the cleanup code like so:
void dealloc()
{
DIGIT *next, *p = head;
while( p )
next = p->next, free( p ), p = next;
}
Franco Martelli <martellif67@gmail.com> writes:Good question ! makes me curious too :)
I'd prefer a mailing-list instead, once finished all the exercises,
I'd like to looking for somebody that he has my same handbook and to
ask him for exchange the exercises for comparison purpose.
Just curious, which handbook is it?
On Tue, Dec 17, 2024 at 16:09:09 -0500, Jeffrey Walton wrote:
I would rewrite the cleanup code like so:
void dealloc()
{
DIGIT *next, *p = head;
while( p )
next = p->next, free( p ), p = next;
}
The logic looks good, but I'm not a fan of this use of the comma operator.
Is that a fashionable thing nowadays?
Especially when teaching a new programmer the ropes, I would stick with
the regular syntax.
void dealloc() {
DIGIT *next, *p = head;
while (p) {
next = p->next;
free(p);
p = next;
}
}
You can put the opening { on the next line if you prefer that way. I
know some people have very strong feeling about that.
18 Dec 2024 05:03:12 tomas@tuxteam.de:
I'm all for concise code, but I usually revert some things in a second
pass when they seem to hurt clarity. After all, you write your code for other people to read it.
As you wrote the code then uness that second pass is weeks or months later then clarity likely still suffers
This is why Ada is so fantastic. Adas main requirements included being optimised for reading and maintenance to reduce the D.O.D.s software costs.
Peter A. Darnell, Philip E. Margolis - "C A Software Engineering Approach":
https://www.google.it/books/edition/_/1nsS5q9aZOUC?hl=it&gbpv=0
Do you have it too? It's pretty old, with some typo, but it looks to
me good.