Yes. Those cases were there to eliminate
the unused variable warnings if (for example)
the mutex was unused or the CACHE_TRY_LOCK
became a noop.
A lot of cases where variables
might or might not have been used have been
cleaned up or NOWARN_UNUSED(x) substituated
(which results in (void)x)) or NOWARN_UNUSED_RETURN
which results in if(x) {} which isn't 'else' safe).
Interestingly we also have UNUSED and INK_UNUSED
which use the __attribute(unused) when available, but
don't do (void)x when it isn't.
The upshot is that all this should probably be
cleaned up.
We should probably eliminate UNUSED and INK_UNUSED
and change NOWARN_UNUSED to use the attribute
if available or and change NOWARN_UNUSED_RETURN to
do {} while (x) for safety.
something for jira?
john
On 1/14/2010 8:35 PM, D.J. Stachniak wrote:
> Hi all,
>
>
>
> I was reading through some of the RAM cache code and stumbled across this:
>
>
>
> http://svn.apache.org/repos/asf/incubator/trafficserver/traffic/branches/dev
> /iocore/cache/RamCache.cc
>
>
>
> int
>
> RamCache::get_lock(INK_MD5 * key, Ptr<IOBufferData> *ret_data, EThread * t,
> inku32 auxkey1, inku32 auxkey2)
>
> {
>
> inku32 k = key->word(3);
>
> int pp = k % n_partitions;
>
> RamCachePartition *p = &partition[pp];
>
> (void) p; // ???
>
> CACHE_TRY_LOCK(l, p->lock, t);
>
>
>
> Or something similar:
>
>
>
> int
> RamCache::put(INK_MD5 * key, IOBufferData * data, EThread * t, inku32
> auxkey1, inku32 auxkey2)
> {
>
> /* equivalent to ram cache disabled */
> if (partition_size == 0)
> return 0;
>
> ProxyMutex *mutex = t->mutex;
> (void) mutex; // ???
> inku32 k = key->word(3);
>
>
>
> I'm wondering what's its (the seemingly no-op void casts) purpose? Is it a
> long, lost holdover from some previous compiler version which required a
> statement like that to keep it quiet for some warning? I've seen it in
> several different files.
>
>
>
> Just curious...didn't know if this was some obscure trick I was unaware of -
> other than quieting a compiler to say a variable's unreferenced...
>
>
>
> Thanks,
>
> D.J. Stachniak
>
>
>
>
