All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: rjohnston@sgi.com, xfs@oss.sgi.com
Subject: Re: [PATCH 2/2] xfsdump: don't do pointer math twice
Date: Fri, 21 Aug 2015 12:24:54 -0500	[thread overview]
Message-ID: <55D75EE6.4080703@sandeen.net> (raw)
In-Reply-To: <20150821193241.973348815@gulag1.americas.sgi.com>

On 8/21/15 9:01 AM, rjohnston@sgi.com wrote:
> The pointer math when calculating the address for the call to memset
> is incorrect, so we are clearing the wrong memory location.
> 
> i2gmap is of type i2gseg_t 
> 
> oldsize has already computed the pointer offset
> 	oldsize = inomap.hnkmaplen * SEGPERHNK * sizeof(i2gseg_t);
> the memset call is using
> 	inomap.i2gmap + oldsize == &inomap.i2gmap[oldsize]
> so we were doing the pointer math twice.
> 
> We already compensate for the length of each item in oldsize so
> adding need to add a (char *) cast to the memset parameter.


What about just doing:

			memset(&inomap.i2gmap[numsegs - SEGPERHNK], 0,
 			       SEGPERHNK * sizeof(i2gseg_t));

which more clearly shows that we're setting the new array members
to zero.

(could do oldsegs = inomap.hnkmaplen * SEGPERHNK; prior to the
hnkmaplen++, if that makes it any more readable...)

*shrug* it seems a little clearer to me, anyway.

Thanks,
-Eric

> ---
>  dump/inomap.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: b/dump/inomap.c
> ===================================================================
> --- a/dump/inomap.c
> +++ b/dump/inomap.c
> @@ -1143,7 +1143,7 @@ cb_add_inogrp( void *arg1, intgen_t fsfd
>  				return -1;
>  
>  			/* zero the new portion of the i2gmap */
> -			memset(inomap.i2gmap + oldsize,
> +			memset((char *)inomap.i2gmap + oldsize,
>  			       0,
>  			       SEGPERHNK * sizeof(i2gseg_t));
>  		}
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-08-21 17:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-21 14:01 [PATCH 0/2] xfsdump: fix problems in cb_add_inogrp rjohnston
2015-08-21 14:01 ` [PATCH 1/2] xfsdump: use 64bit local variables in inode.c rjohnston
2015-08-21 17:03   ` Eric Sandeen
2015-08-21 18:22   ` Eric Sandeen
2015-08-21 14:01 ` [PATCH 2/2] xfsdump: don't do pointer math twice rjohnston
2015-08-21 17:24   ` Eric Sandeen [this message]
2015-08-21 15:47 ` [PATCH 0/2] xfsdump: fix problems in cb_add_inogrp Eric Sandeen
2015-08-21 16:38   ` Rich Johnston
2015-08-21 16:39     ` Eric Sandeen
2015-08-21 16:49       ` Rich Johnston
2015-08-21 20:08   ` Rich Johnston
2015-08-21 20:11     ` Eric Sandeen
2015-08-26 14:33       ` Rich Johnston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55D75EE6.4080703@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=rjohnston@sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.