Thanks for helping me with this issue, Mr. Guenther. I'm not familiar with gdb so it may take some time for me to learn it...however, please note that
cc -O0 wtf.c -o wtf produces a working binary where cc -O2 wtf.c -o wtf causes the program to get stuck. So I have reason to believe GCC's optimizations are faulty. I did attempt to initialize listp as NULL. However, the code then dereferences listp with (*last)->next causing a segmentation fault. On Sun, Feb 7, 2016 at 3:41 PM, Philip Guenther <[email protected]> wrote: > On Sun, Feb 7, 2016 at 12:04 PM, Pavan Maddamsetti > <[email protected]> wrote: >> On Sun, Feb 7, 2016 at 3:01 PM, Pavan Maddamsetti >> <[email protected]> wrote: >>> Thanks for responding. At first, listp points at an uninitialized >>> pointer-sized chunk of stack memory. Depending on the contents of ap >>> and bp, it gets overwritten with either of those two pointers. > > > That may be what you want it to do, but that's not what the code does. > I suggest you compile with -g and walk through it under the debugger, > printing the value of listp before and after you think it's being > changed. > > It may be easier to see if you initialize listp to NULL. You say it's > set before being accessed, so initializing it should have no effect... > > Philip Guenther
