On Wed, Jul 13, 2005 at 02:48:18AM -0400, MenTaLguY wrote:
On Tue, 2005-07-12 at 20:34 +0100, Richard Hughes wrote: So, I have to rely on a proof that my changes don't alter the semantics of affected code, double-checked by a fresh compile and a set of functional tests. If your code was part of the affected, but was #ifdefed out, chances are it got missed by my analysis and probably got broken. And either way I won't know because as far as I can tell everything still compiles and works (it's not like I can try every n^2 combination of #defines).
Hmm... You know...
I think your parenthetical was just rhetorical, but actually with our new automated test harness we now we could actually do this on some regular basis (maybe weekly?)
I did a few grep's through the codebase for unique instances of:
5012 #define 1049 #ifdef 785 #ifndef
If someone could narrow that to a list of no more than, say, 20 cases, it would be feasible to automate running as a weekly check.
Think it's worth doing? I agree that using #ifdef's is poor coding practice, but like you say, sometimes it's unavoidable, and I'm thinking that by automating the testing of those areas we might be able to mitigate their dangers. If someone could provide me with a list of defines to test, it would not be at all difficult to set this up. Even if it doesn't turn up many issues, it would give you a bit more peace of mind about your changes.
(I noticed that after only 2-3 reports from the regular builds that folks have gleefully eliminated all issues found, so I think we need some bigger challenges. *grin*)
Also, fwiw, it is fairly easy for us to hook up automated runs of unit tests now, such as running 'make test' or 'make distcheck'. This isn't hooked up right at the moment but it's very high on the todo list. So if anyone is considering making a unit test, the effort will most definitely not go to waste.
Bryce