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?
Regards
Henrik
Received on Mon Mar 10 2003 - 14:58:43 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:32 MST