Contiguous Array version of Linked List

This is a discussion on Contiguous Array version of Linked List within the C Programming forums, part of the General Programming Boards category; Backstory:
We were given a functional Linked List code and interface, and were told to change it to incorporate an ...

Contiguous Array version of Linked List

Backstory:
We were given a functional Linked List code and interface, and were told to change it to incorporate an array instead of next/prev pointers.
I decided to implement it as an in-order array that shifts whenever things are added.

The Problem:
I am getting segmentation faults whenever I try to add something to the array. The program doesn't seem to like me adding to the element_count variable in the List struct. If I comment the element_count++; it works, but then the underlaying code doesn't print anything out because it still thinks there are 0 elements.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

I left the variable names the same as the code our professor gave us. Personally I don't really like them as my first language was Java (and I am also doing a Rogue-like project in Java that involves a lot of this.variable stuff), but it's not that big of a deal.

The position isn't the same as the position in the array.
If elementArray[0] were filled, its position would be 1, and the element_count would be 1.
It's just a pointer to where you are currently located in the "list"
For example:

[Something1] [Something2] *[Something3]* [Something4]
this->position would be equal to 3.

If it were left at 0 it still works, but to me it makes no sense, because something WAS added to the array/list, and position should be updated. That statement is only reached if there is nothing in the array when AddAfter is called. Regardless, it's not the source of the problem.

What makes me angry is listAddBefore was working once. It would add the element, the interface would print it out, and the position would be properly displayed. Then I did some changes to try and make it work all the time, and it broke.

As far as I can tell, listAddAfter makes perfect sense. If I follow it on paper, it works. Something is breaking in the abstracted code when element_count is incremented.

My code for these functions is identical to my friend's, but his works and mine does not. We tried to fix it for about 45 minutes but couldn't find anything wrong.

And, of course, the rest of your code, since element_count is 2, assumes that elementArray[1] exists. Which it doesn't. It's probably random, or at least NULL or something. And so your code segfaults.

The best way to fix it would be to drop the +1 here:

Code:

this->elementArray[this->position+1] = new;

Try it. It's possible that the change is minor enough that your friend's code has it and yours doesn't and you didn't notice.

Or, of course, now that I think about it, it might be even better to just set position to zero initially instead of 1.

P.S. I don't like those variable names . . . besides the fact that they are keywords in other languages, they're different styles . . . element_count uses "underscore notation", while elementArray uses Camel notation. Of course you can't do anything about it, though.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Can you use a debugger to find out exactly what the data structure looked like when it segfaulted, and of course exactly where it segfaulted? That would greatly help aid your debugging.

Are you using GDB? If so, I can walk you through the commands you'd need to use if you like. Or if you want to post the source code I can compile it on my computer and have a look at it. You probably can't send me the executable because I'm running a 64-bit Debian GNU/Linux system.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

No? Debian is a reasonably common distribution of Linux. In fact I think it's second most common, right after Fedora Code (right, never heard of it either, eh?). In fact, I'm pretty sure that Ubuntu is originally based on Debian.

Anyway, it's irrelevant. Sure, you could send me the folder if you like. But if it's a large project I probably wouldn't be of much help. (Create the archive, rename it to a .TXT, and attach it to a post. That's the easiest way, if it isn't too large.)

Here's what I think you should do. Either use the debugger to walk through the code to see exactly what's happening, or do it automatically with frequent calls to something like the following:

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Fedora Core I use in some computer labs, but not Debian. We were given a choice of either Fedore or Ubuntu during the "Linux install-fest" and I was told Ubuntu would be better.

It's decently big, but the only file that I'm really concerned with is List.c
The rest is just there so that you'd be able to make it and run it (./ListMenu will run it after make, forget if it says that when compiling)

There's a lot of junk in there, but again, List.c and List.h are the only things I altered in any major way. I believe List.c is about 600 lines of code, but it's heavily commented.

I'll try more manual debugging myself. It's frustrating because I can't really directly print out what is in the array because it's a structure inside a structure and the -> trail would be huge.

EDIT:
Using dumpList, element_count is being incremented, there is a structure being placed into elementArray[0], position says as 0... but it still segfaults after list is returned to ListMenu (main).
I have a feeling it's an error with ListMenu printing out the results, but it's worked once or twice in the past.

Maybe it doesn't understand how there can be something in the list, but position is still 0?
The interface is supposed to display asterisks around the current element, but technically the "0" position doesn't exist outside of the Array. It would be 1.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Wow. That looks very convoluted.
No idea listHead was being called from listAddAfter, so I didn't pay it any attention.

That solves that problem, thank you. Now the problem seems to be when adding a second element to the list, but I'm sure it's something inconsistent with the for loops.

The asterisks around the 7-7-7 entry means it's correctly point there, but when I use the listMoveToNth function and set it to 1 nothing is highlighted, but it does not seg fault.
n = 0 is not a valid entry for listMoveToNth.

Is there a legitimate way to set position to 1 when that first element is added?

Yeah, I typed a lot of extra stuff I didn't need to. But debugging tends to be like that. If I just showed you the optimal solution you might think I was extremely insightful or something, which wouldn't help you at all.

The asterisks around the 7-7-7 entry means it's correctly point there, but when I use the listMoveToNth function and set it to 1 nothing is highlighted, but it does not seg fault.
n = 0 is not a valid entry for listMoveToNth.

Well, look at it with a debugger and see what's happening! If you've never used one before, there's no time like the present . . . find a GDB tutorial, for example http://www.cprogramming.com/gdbtutorial.html, and start reading.

Is there a legitimate way to set position to 1 when that first element is added?

Not really. If you're assuming that elementArray[position] is a valid element, then you'll have to use 0 instead of 1. Really, I think that's what you should be doing anyway. It won't take too long, in all likelyhood. The grep only shows [*runs wc*] 30 usages of position, and some of those are comments.

Of course, you could assume that elementArray[position-1] is valid if you wanted to, but I think that would overly complicate things.

"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell

Assuming there is already something in the array. It should cycle through the for loop, copy the element into the adjacent spot, then write over the spot directly infront of position..
list->position is jumping around wildly when I add 7-7-7 over and over.

When I follow it on paper is makes sense. Assume the capital letter is the current position, letters are elements.
Add 'r' After:
vBjk
vBjkk
vBjjk
vBrjk

Oh well, at least it's something I can deal with easily, unlike a seg fault.