projects
projects
This typically means you neglected to properly hook up a prior pointer, but were successful with all the after pointers.
With many of these tests, I simply have the list displayed in reverse, so if problems occur there, see “list displays fine forward but not in reverse”
Any pointer assigned to allocated memory should be some large unrecognizable value. If you notice (especially after calling something like mknode()) an address that is rather low, such as: 0x0100, make sure you didn't assign your pointer incorrectly.
For example, this will result in the above-mentioned scenario:
(*copiedNode) = (Node *) mknode (copiedNode, oldNode -> VALUE);
Casual glances may trick you into thinking that is a call to malloc(), but it is not… it is to mknode(), and remember, the doubly-linked functions return a code_t (an unsigned long long int) to the set status codes as a result of performing that operation.
The pointer left in this state will neither be NULL, nor pointing to accessible memory (the operating system is likely controlling memory that low in address space), so none of your checks for NULL will catch the segmentation fault that will likely manifest in short order.
You'd want something like:
code_t result; ... result = mknode(copiedNode, oldNode -> VALUE);