Indent your code and use code tags to preserve that indentation!
What part of that are you incapable of understanding? If you post an unreadable mess, then we won't bother to try to read it!
What part of that are you incapable of understanding?
b49P23TIvg pointed you to a fatal flaw in your code, but you chose to ignore him!
Originally Posted by b49P23TIvg
Is it important that the first statement in main dereferences uninitialized memory?
Here is the offending code (note the use of indenting and of code tags!
struct queue *b;
for(j=0; j<3; j++)
Direct your attention to the line in red. What is plist pointing to? IOW, what is the value of plist? You don't know, do you? Neither do I, because it is an uninitialized pointer!
That means that it contains any possible random garbage
. It could be pointing anywhere. Using an uninitialized pointer is like standing in the middle of a crowded room, closing your eyes and pointing a loaded pistol in any random direction, and squeezing the trigger. Who in their right mind would do such a thing? Who in their right mind would use an uninitialized pointer
? Both acts are just as reckless, irresponsible, and reprehensible. As is ignoring somebody's warnings when you are about to perform such a deed, especially when you went through the motions of asking that person for advice.
If plist is supposed to point to the start of the list, then, since there is no list at the start of the program, it needs to be initialized to indicate that there is no list. Then after that, you cannot change it or else you will have dropped that list. Consider this:
for(q=*plist; q->next!=NULL; q=q->next);
You just dropped part of that list. Besides the fact that that is a major memory leak (a very insidious type of bug that is notoriously difficult to find, even though it is easy to correct), you have also lost a big chunk of data. Maybe you have a good reason to do that, but given the absence of comments, meaningful variables, or any kind of explanation of what your program is supposed to do, we have no way of knowing that. As b49P23TIvg commented about your code: "It's a mess with code tags too." Communication is an essential skill in programming. You need to write your code so that another programmer can pick it up and immediately be able to understand it. Meaningful variable names and informative comments are an essential part of that communication, as is making your code readable
through proper formatting, which includes indenting your code
and taking the proper steps to preserve that indentation (which here involves the use of code tags
And what is that nonsense about with making plist a pointer to a pointer? All you ever do with it is dereference it! All you're doing is making your code even more confusing than it already is.
If we cannot understand what you are trying to do in that code, then we cannot help you.
If you ignore what we tell you, then we cannot help you.
This is what I get when I compile your code (MingW gcc on WinXP):
| C:TEST>gcc -Wall tendo2.c |
tendo2.c: In function `getnode':
tendo2.c:22: warning: implicit declaration of function `malloc'
tendo2.c: In function `freenode':
tendo2.c:28: warning: implicit declaration of function `free'
tendo2.c: In function `main':
tendo2.c:39: warning: unused variable `plist1'
tendo2.c:37: warning: unused variable `b'
You knew to #include stdio.h in order to provide the prototypes for the standard I/O functions, scanf and printf. So why didn't you do the same for malloc and free? Or for NULL? malloc and free are prototyped in two header files: malloc.h and stdlib.h. In addition, NULL is declared in stdlib.h.
The effects of not #include'ing a library function's header file is unpredictable. Sometimes you can get away with it. We have also seen it cause the program to crash, or at least for the function being called to completely fail to function properly.
Why neglect to provide the compiler with the information that it needs to do its job? Why neglect to #include the header files that it needs?
Why did you ignore the warnings you got because of that oversight? Only a fool ignores warnings.
Are you compiling with warnings turned off? That is even more foolhardy!
Until your program compiles cleaning (no errors or warnings which warnings turned on and up!
), don't even bother to try to run it. Your program is broken. Any output or behavior your broken program would produce is absolutely meaningless.
If your program is broken, then fix it!
Only after you have fixed it can you try to run it and only then can you deal with unexpected output.