On Mon, 2006-09-11 at 14:23 +1000, Tony Breeds wrote:
> Sorry I stuffed up the CC line on this email.
> Anyone care to comment on the patch included?
>
> ----- Forwarded message from Tony Breeds <[EMAIL PROTECTED]> -----
>
> Date: Mon, 11 Sep 2006 14:12:29 +1000
> From: Tony Breeds <[EMAIL PROTECTED]>
> To: David Farning <[EMAIL PROTECTED]>
> Cc: kj <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Subject: Re: [KJ] fixing compile warnings
>
> On Sun, Sep 10, 2006 at 09:30:31PM -0500, David Farning wrote:
> > I am working my way through the compile warnings in /fs
> >
> > I have come across this set of warning
Yeah, I just recently started using gcc-4.1.1 and see the same warning.
> >
> > fs/jfs/jfs_txnmgr.c: In function ???txCommit???:
> > fs/jfs/jfs_txnmgr.c:1922: warning: ???pxd.addr2??? may be used uninitialized
> > in this function
> > fs/jfs/jfs_txnmgr.c:1922: warning: ???pxd.addr1??? may be used uninitialized
> > in this function
> > fs/jfs/jfs_txnmgr.c:1922: warning: ???pxd.len??? may be used uninitialized
> > in this function
>
> If I read xtLog() correctly there is no way pxd can be used with out
> being initialised.
>
> The code goes something like:
> xtLog()
> {
> ...
> if (tlck->type & tlckTRUNCATE) {
> pxd_t pxd; /* truncated extent of xad */
> ....
> if (twm == next - 1) {
> ...
> pxd = pxdlock->pxd; /* save to format maplock */
> ...
> }
> ...
> if (twm == next - 1) {
> ...
> pxdlock->pxd = pxd;
> ...
> }
> }
> ...
> }
>
> With no changes to twm or next between the 2 access.
>
> > What is the proper (kernel) way to initialize pxd_t in jfs_txnmgr.c to
> > silence the warnings?
>
> I guess you could do something like:
>
> ---
> if (tlck->type & tlckTRUNCATE) {
> - pxd_t pxd; /* truncated extent of xad */
> + /* truncated extent of xad */
> + pxd_t pxd = {0, 0, 0}; /* FIXME: shutup GCC */
> int twm;
> ---
>
> But I don't really think that's acceptable.
>
I'm wondering if the best solution is to just make the assignment
unconditional. It would probably be more efficient than zeroing it and
doing the test.
> However, in looking at this question I found a shadow variable, I think the
> patch below is a reasonable fix.
Makes sense. I'll pull this one in.
> From: Tony Breeds <[EMAIL PROTECTED]>
>
> Remove shadow variable from fs/jfs/jfs_txnmgr.c:xtLog()
>
> Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
>
> ---
>
> fs/jfs/jfs_txnmgr.c | 2 --
> ---
>
> --- a/fs/jfs/jfs_txnmgr.c
> +++ b/fs/jfs/jfs_txnmgr.c
> @@ -2026,8 +2026,6 @@ static void xtLog(struct jfs_log * log,
> * truncate entry XAD[twm == next - 1]:
> */
> if (twm == next - 1) {
> - struct pxd_lock *pxdlock;
> -
> /* format a maplock for txUpdateMap() to update bmap
> * to free truncated delta extent of the truncated
> * entry XAD[next - 1];
>
> ---
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion
