Gary E. Miller via devel <devel@ntpsec.org>: > Yo Ian! > > On Tue, 30 May 2017 16:34:07 -0500 > Ian Bruene via devel <devel@ntpsec.org> wrote: > > > Every instance I've seen has the logging code enclosed in an #ifdef > > block for the debug compilation switch, whether directly where it is > > used, of inside of a macro. It would appear that someone began to > > replace the explicit if debugs with macros, > > That might be a good place for you to start. You make a few simple > decisions, then replace old code a few files at a time, with the > single, new, one true, macro. > > > but never completed it > > for unknown reasons. > > Once you start, you'll know why. The code is a lot easier to deal with > now, but it will still be a ton of little changes to the ton of slightly > different peices of old code. So you need to actually look, and think > about, each change. I'd start with one mental template, change all > those instances, then go on the next. That way you only need to think > for each template, then cut/paste for an hour.
I wasn't actually planning to assign this job to Ian yet, but Gary's
plan is so good that I think we'll roll with it.
Ian, this is about as painless and low-risk a way to start you on modifying
C code as I can imagine. From the point of view of advancing your training
it's too good an opportunity to miss.
So, yeah. Audit the macros, choose one true name and replace all the others.
Also, complete the replacement of explicit "if (debug..." clauses.
Pro tip: doing a relatively boring search-and-destroy like this
without errors is all about attention management. You can't be fully
on all the time, your brain isn't evolved for that.
Therefore, don't try doing the callsites in any predetermined order. Instead,
do these three srteps:
1. Identify the easy cases - that is, the ones you can do with a mechanical
or semi-mechanical procedure.
2. Then do a first pass where you change all the easy cases (the ones
you can do half-asleep) on autopilot, skipping any that have
complications.
3. Then go back and do the relative few that have complications, paying
full attention to each one.
Sometime there are couple of tiers of easy cases, so you'll loop back
to step 2. The point, be lazy. Don't spend more attention on the easy
cases than you have to, so you can avoid spending less than you should
on the tricky ones.
As you gain more experience, you will find that this is *often* a good
way to partition tasks.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
