Skip to contentSkip to conversation

xfsprogs: useless code blocks

DISCUSSION Jan Tulak 2 participants 3 messages Jul 20, 2015 – Jul 21, 2015 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jan Tulak

author
#1 lore raw

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 [email protected], 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

Signature · 7 lines
Jan Tulak
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
#2 lore raw
Quoted 10 lines · 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 [email protected], who didn't wrote here since 2006, so I find

[email protected] will get you that same person ;)

Quoted 2 lines

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?

Quoted 6 lines

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.

Signature · 7 lines
Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
author
#3 lore raw

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 -----

Quoted 18 lines

From: "Dave Chinner" <[email protected]>
To: "Jan Tulak" <[email protected]>
Cc: "xfs-oss" <[email protected]>
Sent: Tuesday, July 21, 2015 8:37:38 AM
Subject: Re: xfsprogs: useless code blocks

Quoted 10 lines · 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 [email protected], who didn't wrote here since 2006, so I find

Quoted 8 lines

[email protected] will get you that same person ;)

Quoted 2 lines

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.

Quoted 5 lines
Quoted 5 lines

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.

Quoted 7 lines
Quoted 1 line

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

Signature · 7 lines
Jan Tulak
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs