linux-kernel - Re: Re: [PATCH] btrfs: Simplify offset calculation method for ctree.h

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20091218141003.GB3202@think>
Date:	Fri, 18 Dec 2009 09:10:03 -0500
From:	Chris Mason <chris.mason@...cle.com>
To:	Zhaolei <zhaolei@...fujitsu.com>
Cc:	sniper <s3c24xx@...il.com>,
	"linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH] btrfs: Simplify offset calculation method for
 ctree.h

On Fri, Dec 18, 2009 at 01:51:14PM +0800, Zhaolei wrote:
> sniper wrote:
> > No, many pointers in btrfs function arguments are not pointing to an
> > absolute address, but relative to the start address of extent.
> > Take following function as example, argument inode_item is an offset
> > value to the beginning of leaf. So we can't reach its member with
> > &inode_item->xxx
> 
> Notice that we are not reach its member, we are getting pointer of its
> member with &inode_item->mtime.
> This operation have same effect as old one.

It relies on gcc doing something specific with the pointer address
manipulation while the original code makes it clear we're just taking
the offset.  We do rely on gcc being gcc in lots of places in the code,
but in this case I prefer the offsetof.

-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/