trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Call <>
Subject Re: [DISCUSS] Change SDK return values?
Date Fri, 18 Feb 2011 00:18:11 GMT
I agree with the changes.  It would be nice to have standard error 
return values across all the functions.


On 02/17/2011 04:11 PM, Leif Hedstrom wrote:
> 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

View raw message