On Fri, Aug 22, 2003 at 09:54:27PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > +/* driver entry point for term */
> > > +static void __exit
> > > +drv_exit(void)
> > > +{
> > > +	dprintk(KERN_INFO PFX "drv_exit\n");
> > > +
> > > +	cpufreq_unregister_driver(&cpufreq_amd64_driver);
> > > +	if (ppst) {
> > > +		kfree(ppst);
> > 
> > kfree(NULL) is fine.
> > 
> > > +		ppst = 0;
> > 
> > this should be ppst = NULL but in fact is completly superflous as
> > the module is gone afterwards.
> 
> Ok.

Guys, good programming practise would leave this in. If you want,
you could add a comment that in the current code, this is superfluous. 

In the current code it is also not performance critical. So to maintain
good programming practise I would recommend to leave the ppst = NULL. 

The code might get copied somewhere else. In that case the ppst=NULL
will indicate that it's pointing nowhere. Also, this will prevent
the bug from becoming a bug: The developer will immediately see that
he's made a mistake and fix it before it becomes a real bug. But
if you leave the dangling pointer around, you will address memory
that until recently contained believable data. So it will work
most of the time. Only when an interrupt comes by  that allocates
memory and actually writes the relevant parts will you get problems.
That might be quite rare and very difficult to track down. 

In writing code, simple bugs are not a problem. These are the bugs
that show up while compiling the code, or in first testing. 

You should try to prevent the hard bugs with good programming 
practise. These are the bugs where you get a report: My server
locks up every day or two. It's too long to sit by the machine 
to wait for it to happen, it's too long to log everything, but 
it's way too short to say: Sorry, you'll have to live with it.

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
**** "Linux is like a wigwam -  no windows, no gates, apache inside!" ****
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/