www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/08/16/11:41:12

From: kagel AT quasar DOT bloomberg DOT com
Date: Fri, 16 Aug 1996 11:31:19 -0400
Message-Id: <9608161531.AA05913@quasar.bloomberg.com >
To: leathm AT gbrmpa DOT gov DOT au
Cc: djgpp AT delorie DOT com
In-Reply-To: <199608140425.OAA01240@gbrmpa.gov.au> (message from Leath Muller on Wed, 14 Aug 1996 14:25:48 +1000 (EST))
Subject: Re: bug with gcc???
Reply-To: kagel AT dg1 DOT bloomberg DOT com

   From: Leath Muller <leathm AT gbrmpa DOT gov DOT au>
   Date: Wed, 14 Aug 1996 14:25:48 +1000 (EST)

   I finally got my code to work, and I have to admit I think it's peculiar as
   to why...

   The origal code was something like:

	   temp = head_of_list;
	   while (temp->next != NULL)
		   temp = temp->next;

   This died a horrible death, and yet when I changed the code to the following:

	   temp = head_of_list;
	   done = FALSE;
	   while (!done)
	   {
		   if (temp->next == NULL)
			   done = TRUE;
		   else
			   temp = temp->next;
	   }

   It works fine...

   Is this a bug with gcc??? Or what??? :|

Just like loading the program into a debugger the recoding may have shifted the
code and data around.  Make certain that the next pointer at the end of the
list has indeed been initialized to NULL.  Did you try to put a printf into the
original loop?  It may show the problem, but if the problem goes away again
then it is surely that the next pointer at the end of the list is garbage
rather than NULL.  Are the list elements on the stack (like allocated by
alloca() or pulled from an automatic array)?  Moving code or loading a debugger
affects the programs stack position and can cause these kinds of symptoms in
automatic and other stack related objects.

-- 
Art S. Kagel, kagel AT quasar DOT bloomberg DOT com

A proverb is no proverb to you 'till life has illustrated it.  -- John Keats

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019