On 27/08/07, Ron Blaschke <[EMAIL PROTECTED]> wrote: > Paul Cochrane wrote: > > On 26/08/07, chromatic <[EMAIL PROTECTED]> wrote: > >> On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote: > >> > >>> The variable ins2 is freed by the call to subst_ins() but is then > >>> later assigned to later in the if-block. Um, this isn't a good idea > >>> is it? The variable shouldn't be freed in subst_ins() I don't think, > >>> so shouldn't we instead have the line: > >>> > >>> subst_ins(unit, ins2, tmp, 0); > >>> > >>> (where setting the argument to 0 means *not* freeing the variable). > >>> > >>> Is this the right thing to do? Just wanted to ask the opinion of our > >>> resident gurus before I went and broke something... > >> free() takes a pointer and frees the memory pointed at. The variable > >> itself is > >> just a storage location for that pointer. Maybe reusing the variable name > >> is > >> confusing to humans, but I don't see any particular trouble for the > >> computer > >> here. > > > > Ok, I'll just tell the Coverity thing to ignore that particular warning. > > Just curious, but could you please post the exact wording of the warning?
Sure. I'll have to piece this together a bit from the various pieces of info from the web app output, so please, bear with me. Warning: USE_AFTER_FREE File: compilers/imcc/optimizer.c Function: constant_propagation Description: Using freed pointer "(ins)->next" Help output associated with warning: 5.4.2. USE_AFTER_FREE The USE_AFTER_FREE checker finds code that uses freed memory. Specifically, double frees and dereferences of freed pointers are detected. 5.4.2.1. Impact Once memory has been freed, it cannot be safely used. A double free of a pointer can result in corruption of the memory free list, which can cause undefined behavior including memory corruption and crashes. Dereferencing a freed pointer is also dangerous because the pointer's value may have been changed to a non-pointer value or a pointer to an arbitrary location. Double frees are especially dangerous in multi-threaded programs because freed memory may be allocated to another thread. For example, double freeing a pointer in a multi-threaded program may cause another (random) thread to be using memory that is also on the free list. Using freed memory in this way may result in a race-condition which can be very difficult to track down. HTH Paul
