Dude. That is super cool. I had been vaguely aware of gdb before but never used it to examine variables or anything useful.
So I got a segfault after initializing listp as NULL, which appears to be a macro for (void *) 0 from my system header files. My thought was that this occurred because I first dereferenced last to yield listp, and then used the arrow operator to dereference the member next. Isn't listp->next equivalent to (*listp).next ? In any case, I have surely made a novice error. I will follow Philip Guenther's advice and go to a C programming forum first before disturbing this mailing list. On Sun, Feb 7, 2016 at 5:31 PM, Stuart Henderson <s...@spacehopper.org> wrote: > On 2016-02-07, Pavan Maddamsetti <pavan.maddamse...@gmail.com> wrote: >> 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. > > That is *sometimes* the case, but it usually just means that the program > relies on something which is undefined behaviour; compilers are allowed > to interpret this how they want, and often do, especially where the > optimizer is concerned. > > Quick intro: compile with -g then "gdb ./wtf", "break main" (or some > other function), "run", step with 'n', use 'print' to examine variables. > Examine online help / docs for more. > >> I did attempt to initialize listp as NULL. However, the code then >> dereferences listp with (*last)->next causing a segmentation fault. > > Didn't you say that it gets overwritten with either ap or bp though? > If that's the case, how is it dereferencing a null pointer?
