[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] fix for issue #591

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2002-01-20 21:27:36 CET

On Sun, Jan 20, 2002 at 07:23:25PM +0000, Philip Martin wrote:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>
> > > > + apr_hash_this(hi, (const void **)&key, NULL, (void **)&val);
> > >
> > > Existing code generally avoids the casts and declares
> > >
> > > const void *key;
> > > apr_ssize_t klen;
> > > void *val;
> > > apr_hash_this (hi, &key, &klen, &val);
> >
> > wouldn't i just have to cast it later when i use them?
>
> In this case I don't think so, they simply get passed to functions
> that take a pointer.

i gave it a shot, and switching to const void *key and void *val in
libsvn_ra_dav/fetch.c simply results in warnings from gcc about using
void * in arithmetic and dereferencing void pointers. plus, it
appears that the rest of the file uses apr_hash_this in the same way i
was originally using it (with the casts).

in libsvn_client/copy.c however, i can just use const void *key, and
void *val instead of using const char * and svn_string_t *, and it
works fine.

i don't have any strong feelings one way or the other, but what is the
prefered style? i imagine one should avoid the casts if at all
possible, so that's how i'm leaving it at this point. copy.c doesn't
use casts, and fetch.c does, since it needs to access the internals of
what it's getting out of the hash.

-garrett

-- 
garrett rooney                     Unix was not designed to stop you from 
rooneg@electricjellyfish.net       doing stupid things, because that would  
http://electricjellyfish.net/      stop you from doing clever things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:57 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.