Re: Failing build on opensolaris

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Thu, 28 Oct 2010 13:55:05 -0600

On 10/28/2010 01:09 PM, Kinkie wrote:

> Then, if I remember it correctly, that code is broken and needs to be fixed :(

Isn't that what you were doing? If you want to fix the code _and_ follow
the cbdata API rules, use CbcPointer instead of a raw queue pointer. The
rules were not required for C structures to work and are difficult to
implement correctly for complex C++ classes. CbcPointer solves that problem.

Keep in mind that a lot of cbdata-using code violates these very good
rules, and most violations are, like this one, benign from code logic
point of view. That is why these violations are still being copied and
added to Squid. Hopefully, we will not make the same mistake twice when
cbdata API is updated.

HTH,

Alex.

> On Thursday, October 28, 2010, Henrik Nordström
> <henrik_at_henriknordstrom.net> wrote:
>> ons 2010-10-27 klockan 20:29 +0200 skrev Kinkie:
>>> The build is failing on
>>>
>>> ../../src/comm.cc: In member function `void
>>> ClientInfo::setWriteLimiter(int, double, double)':
>>> ../../src/comm.cc:2156: warning: right-hand operand of comma has no effect
>>>
>>> That line is
>>> cbdataReference(quotaQueue);
>>>
>>> where in cbdata.h
>>> #define cbdataReference(var) (cbdataInternalLock(var), var)
>>>
>>> Fixing this would seem simple, but it probably breaks encapsulation
>>> (that "Internal" soeems suspicious to me).
>>> Anyone willing to take on this, or to share a hint on how to do it?
>>
>>
>> The compiler is right in erroring out on this. The result of
>> cbdataReference MUST NOT be thrown away. It's your reference to the
>> object and should later be passed to cbdataReferenceDone.
>>
>> It's also usable for accessing the object, but it's not really the
>> intention that holders of cbdata references should access the content of
>> the object, just pass it back in a callback.
>>
>> Regards
>> Henrik
>>
>>
>
Received on Thu Oct 28 2010 - 19:55:20 MDT

This archive was generated by hypermail 2.2.0 : Fri Oct 29 2010 - 12:00:06 MDT