On 02/11/2011 08:40 AM, Leif Hedstrom wrote:
On 02/11/2011 06:03 AM, Igor Galić wrote:
Right now, we have:
[snip]
~35 places where we'd need to change that.
39 if we count it like this: `` ack -l '(!|=)=\s*TS_ERROR' | wc -l ''
Might be worth the effort, I'm at least +0.5
Still doable.
Thinking about this a little more, and I'm still not entirely opposed
to #3 (it definitely has some merits), another concern is how people
would use this extra information. I mean, if the common pattern is still
So, I've finished most of this work, and while reading code, and
discussing on IRC, I think we'll need to make one more change. The issue
is that a few APIs uses an "int" return code as a boolean, where 1 means
"success" (e.g. you found a header), and 0 means "failure" (e.g. not
found). I'd like to propose that we change these to use TSReturnCode as
well (TS_SUCCESS and TS_ERROR).
The downside to this is that such APIs now requires code changes in any
existing plugins. It's not impossible to find such cases, but a little
problematic (since TS_SUCCESS == 0, the logic is inversed). I think I
can whip up a Perl script that would produce good warnings on areas in
existing plugin code that the author might need to address the API
changes. A few example APIs that would change include
TSMgmtStringGet()
TSIPLookupMatchFirst()
Are there any objections or other concerns about this change? It should
be notable that there are plenty of other API changes, but in most
cases, the compilers will detect / complain on those. For this, it would
not.
-- Leif
