[tor-dev] #if 0 unused functions?

teor teor2345 at gmail.com
Sun Mar 22 13:41:46 UTC 2015


> Date: Sun, 22 Mar 2015 05:12:03 +0100
> From: Sebastian Hahn <sebastian at torproject.org>
> To: tor-dev at lists.torproject.org
> 
> Hi there,
> 
> we have some functions which we never call anywhere. In many cases, it
> appears we shouldn't delete them from the source because they "belong"
> there - the thing I initially stumbled across was
> ed25519_seckey_write_to_file(), for example. But I also don't see why
> compiling it and potentially including it in our binary makes any sense.
> 
> Thoughts?
> 
> Cheers
> Sebastian

I'm think that removing / disabling unused code is a great idea, but I wonder what happens over the long term:

[How] do we prevent bit-rot on the disabled code?

Does the disabled code have unit tests?
Should we add unit tests or keep them active to prevent bit-rot?
Or should any unit tests be disabled too?

I wonder if we could unit test unused code, but not link it into the tor binary.
This would make sure it works if we ever want to use it in future, but without the risks and performance impacts of including unused code in the binary.

There could be issues with this strategy that I haven't thought of. Like the added maintenance cost involved in keeping unused code and unit tests up-to-date.

Perhaps we could:
* remove entirely if we're unlikely to ever use the code,
* disable if we want to keep it around for future reference, and
* unit test it, but not link it in to the tor binary, if we think we'll use it soon.

Which category do most of the unused functions fall into?

teor

teor2345 at gmail dot com
pgp 0xABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im
OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150323/43946b53/attachment.sig>


More information about the tor-dev mailing list