[GSOC] Help regarding deleting unused functions

Peter Dufault dufault at hda.com
Sun Jul 14 13:36:02 UTC 2013


On Jul 14, 2013, at 04:01 , Vipul Nayyar <nayyar_vipul at yahoo.com> wrote:

> Hello,
> 
> While doing my current task of removing legacy code, after compilation, I receive warnings for a certain function, that is defined but not used. As suggested by Sebastian, I delete it, after checking whether it's really been not called anywhere in the current file, and outside it. Most of the functions that I'm talking about right now are static, or supposed to be static.
> 
> After re-compilation, warning for that deleted function is obviously gone, but there are new warnings of functions defined but not used. So, ultimately I have to delete these static functions who are inter-related(calling each other), in order to remove the warnings. Currently I was trying my hand on i386 pc386 BSP, where I encountered this thing. 
> 
> I really don't know whether deleting these multiple inter-related static functions is the right way to go or a horribly wrong one.
> 
> Hoping to hear soon.
> 
> Regards
> Vipul Nayyar 
> 
> _______________________________________________


This is hard to answer.  The question is whether the functionality that this is implementing is of any use in the future, as it apparently was of some use in the past.

When confronted with this I usually choose  a pre-processor define to associate with the static functions.  Then I go through and conditionally disable the entire family of functions.  After that I have a good understanding of its scope what it is doing, and I can then go and remove it completely or decide that there is some reason I still want to keep it around.

If I do want to keep it around I do not leave conditionally compiled, completely unused code intact in a source files.  Since it will never be compiled on RTEMS  it will rot quickly and just become confusing, uncompilable cruft. 

However, let's say this code implements hooks for some sort of memory protection that it isn't implemented in RTEMS, but as we know there is work going on on this.  So if I wanted to keep it around I would move the code to a new .c file, add a public interface so the static functions were used, remove the conditional compilation, and describe why I kept it and that it isn't really tested.  It would then be compiled so it won't get any worse over time.

The reason to move it to another file is so it is still compiled, but it won't increase code footprint. Many RTEMS applications are memory constrained.

Joel might have a different answer.  I know he is concerned with coverage and this complicates that.,

 "The code already can't be trusted, it hasn't been used for who knows how long, remove it with extreme prejudice" is a much simpler and perfectly defendable answer.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130714/3f450906/attachment.html>


More information about the devel mailing list