Re: The use of cbdataFree() in HEAD

On Tue, 2003-03-11 at 08:58, Henrik Nordstrom wrote:
> The following uses of cbdataFree in HEAD is dubious:
>
> src/client_side_reply.cc:253: cbdataFree ((clientReplyContext
> *)address);
> src/store_client.cc:79: cbdataFree ((store_client *)address);
> src/ESI.cc:2425: cbdataFree ((esiRemove *)address);
> src/ESI.cc:2775: cbdataFree ((esiAttempt *)address);
> src/ESI.cc:2800: cbdataFree ((esiExcept *)address);
> src/ESI.cc:2825: cbdataFree ((esiVar *)address);
> src/ESI.cc:2879: cbdataFree ((esiVarState *)address);
> src/ESI.cc:3950: cbdataFree ((esiOtherwise *)address);
> src/ESISegment.cc:166: cbdataFree ((ESISegment *)address);
>
>
>
> I think in all cases the typecast should be removed as cbdataFree()
> expects a L-VALUE (variable or memory area which can be on the left
> of an assignment operation), not a R-VALUE (calulated value,
> including typecasts).
>
> cbdataFree is defined as:
>
> #define cbdataFree(var) do {if (var)
> {cbdataInternalFree(var); var = NULL;}} while(0)
>
> and as you can see the typecast does not make much sense in such
> context, and infact breaks the second part of the statement as
> "(store_client *)address = NULL;" is not directly a sane legal
> statement.
>
> Robert: Is there any C++ specific reason to these typecasts?

No, they where an (incorrect) idiom I came up with during the c++
migration... and I'll fix them up shortly.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.