xfsprogs: useless code blocks

xfsprogs: useless code blocks

[Jan Tulak]

Hi all,

I found these useless bits of code in xfsprogs:

repair/incore_ino.c:575-576: 
if (ino_rec->ino_startnum == 0)
  ino_rec = ino_rec;

This one is pretty clear. It is there since 2001 (commit 2bd0ea187 
by nathans@sgi.com, who didn't wrote here since 2006, so I find 
CC-ing him useless). It looks like a forgotten code which doesn't 
do anything, but I ask in case it is a hidden bug.

And:

db/check.c:3035, 3037: Always true expression, as be32_to_cpu() 
translates to __u32 type and unsigned can't be less than zero.

be32_to_cpu(free->hdr.nvalid) < 0 ||

Is there any reason for these tests? I get different type sizes, or
endians as platform dependent, but signed/unsigned? Or it is
a big/little endian conversion hack?

Cheers,
Jan

-- 
Jan Tulak
jtulak@redhat.com

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

Re: xfsprogs: useless code blocks

[Dave Chinner]

On Mon, Jul 20, 2015 at 09:57:46AM -0400, Jan Tulak wrote:
> Hi all,
> 
> I found these useless bits of code in xfsprogs:
> 
> repair/incore_ino.c:575-576: 
> if (ino_rec->ino_startnum == 0)
>   ino_rec = ino_rec;
> 
> This one is pretty clear. It is there since 2001 (commit 2bd0ea187 
> by nathans@sgi.com, who didn't wrote here since 2006, so I find 

nathans@redhat.com will get you that same person ;)

> CC-ing him useless). It looks like a forgotten code which doesn't 
> do anything, but I ask in case it is a hidden bug.

Who knows? It came from the Irix code base by the look of it, so
maybe it was just working around a compiler bug?

> And:
> 
> db/check.c:3035, 3037: Always true expression, as be32_to_cpu() 
> translates to __u32 type and unsigned can't be less than zero.
> 
> be32_to_cpu(free->hdr.nvalid) < 0 ||

The old endian conversion stuff in userspace needed that. When we
converted it to the same as the kernel macros, we didn't change any
of the logic. gcc isn't warning about this on x86-64, so in general
signed/unsigned stuff goes unnoticed.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: xfsprogs: useless code blocks

[Jan Tulak]

Hi Nathan,
I'm sending this also to you, as it is about one old your patch
you posted to xfsprogs. Can you look at the two lines, if you
recall their purpose? :-)

----- Original Message -----
> From: "Dave Chinner" <david@fromorbit.com>
> To: "Jan Tulak" <jtulak@redhat.com>
> Cc: "xfs-oss" <xfs@oss.sgi.com>
> Sent: Tuesday, July 21, 2015 8:37:38 AM
> Subject: Re: xfsprogs: useless code blocks
> 
> On Mon, Jul 20, 2015 at 09:57:46AM -0400, Jan Tulak wrote:
> > Hi all,
> > 
> > I found these useless bits of code in xfsprogs:
> > 
> > repair/incore_ino.c:575-576:
> > if (ino_rec->ino_startnum == 0)
> >   ino_rec = ino_rec;
> > 
> > This one is pretty clear. It is there since 2001 (commit 2bd0ea187
> > by nathans@sgi.com, who didn't wrote here since 2006, so I find
> 
> nathans@redhat.com will get you that same person ;)
> 
> > CC-ing him useless). It looks like a forgotten code which doesn't
> > do anything, but I ask in case it is a hidden bug.
> 
> Who knows? It came from the Irix code base by the look of it, so
> maybe it was just working around a compiler bug?
> 

All right, I'm adding him, we will see.

> > And:
> > 
> > db/check.c:3035, 3037: Always true expression, as be32_to_cpu()
> > translates to __u32 type and unsigned can't be less than zero.
> > 
> > be32_to_cpu(free->hdr.nvalid) < 0 ||
> 
> The old endian conversion stuff in userspace needed that. When we
> converted it to the same as the kernel macros, we didn't change any
> of the logic. gcc isn't warning about this on x86-64, so in general
> signed/unsigned stuff goes unnoticed.
> 

I found it during my OS X porting - clang complains. So I will remove it,
although I will wait at first if Nathan has anything to say about the
ino_rec self-assignment.

Cheers,
Jan
-- 
Jan Tulak
jtulak@redhat.com

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