assigning a pointer to linked list to stuct element, changes list

[Alastair Houghton]

Julian Cooling wrote:
> 
> Hi,
> 
> I was compiling my C program on a computer:
> 
> $ uname -a
> Linux jack 2.2.5-22 #1 Wed Jun 2 08:45:51 EDT 1999 i586 unknown
> $ cat /etc/redhat-release
> Red Hat Linux release 6.0 (Hedwig)
> $ date
> Wed Nov 17 19:53:31 CST 1999
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
> gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> 
> I used -g every time but the bug is there without it.
> 
> The bug appears when I assign a pointer (which is first element in a linked
> list) to a pointer of the same type.  The second and succeeding elements of
> the list change to point to the first (i.e. the list becomes a loop).
> 
> I included 5 attachments.
> 
> 1) The C file (edited down severely)
> 2) The .h file (it now lives in the same directory as the C file)
> 3) The output of gcc -E
> 4) The output with the bug
> 5) The output with the bug fixed (by uncommenting a line in the .h file)
> 
> I hope these all help.  Sorry about the quality of the C code - bug tracking
> via code is not pretty and gdb wasn't much help in this case.
> 
> regards,
> 
> Julian Cooling

Mmmm. I think you should take another look at your program
code... I don't think this is a compiler bug; I think you'll
find it has to do with the fact that your code is broken.

You aren't initialising "mpool_node" correctly; you need
to fill in your next pointer for a start. Also I'm a little
dubious about some of the other code in the program. I
suspect you'll find that you are explicitly creating the loop
(if you re-read your program *carefully*). It would help
if you changed the variable "next" to have a better name.

I do have a few suggestions that would make life easier
for you (as well as anyone else that needs to read your
program):

  1. Use ANSI/ISO C. It's much clearer and will show up
     some bugs in your program (for example, some of your
     functions are declared as returning integers, but
     don't always do so).

  2. Space your code and comment your code better. It
     makes it easier to understand what you're doing.
     Most people learn this through bitter experience
     because they don't listen to people who say they
     should be doing it.

  3. Avoid confusing variable names - e.g. don't use
     a variable called "next" if it is of a type that
     contains a member called "next".

Check your program over again. Currently it has bugs itself,
which need to be eliminated before any compiler bugs could
be investigated.

____________________________________________________________
Alastair Houghton                              ajh8@ic.ac.uk
(ISE 4)                             Imperial College, London