[1/8] reiserfs:stree.c Fix variable set but not used.

  Not sure if this is correct or not.
the below patch gets rid of this warning message
produced by gcc 4.6.0

fs/reiserfs/stree.c: In function 'search_by_key':
fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used

 Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>

---
 fs/reiserfs/stree.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)
  

On 13:26 Mon 14 Jun     , Justin P. Mattock wrote:
> @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,	/* Key to s
>  
>  	pathrelse(search_path);
>  
> -	right_neighbor_of_leaf_node = 0;
> -
> +	

This hunk introduces whitespace on the empty line, which is not cool.

>  	/* With each iteration of this loop we search through the items in the
>  	   current node, and calculate the next current node(next path element)
>  	   for the next iteration of this loop.. */
> @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,	/* Key to s
>  			   starting from the root. */
>  			block_number = SB_ROOT_BLOCK(sb);
>  			expected_level = -1;
> -			right_neighbor_of_leaf_node = 0;
> -
> +			

Here, too.

Most of the patches in this series have similar issues.
  

Justin P. Mattock wrote:
> Not sure if this is correct or not.
> the below patch gets rid of this warning message
> produced by gcc 4.6.0
>
> fs/reiserfs/stree.c: In function 'search_by_key':
> fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used
>
>  Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>   

Acked-by: Edward Shishkin <edward.shishkin@gmail.com>

> ---
>  fs/reiserfs/stree.c |    7 ++-----
>  1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c
> index 313d39d..73086ad 100644
> --- a/fs/reiserfs/stree.c
> +++ b/fs/reiserfs/stree.c
> @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,	/* Key to s
>  	struct buffer_head *bh;
>  	struct path_element *last_element;
>  	int node_level, retval;
> -	int right_neighbor_of_leaf_node;
>  	int fs_gen;
>  	struct buffer_head *reada_bh[SEARCH_BY_KEY_READA];
>  	b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA];
> @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,	/* Key to s
>  
>  	pathrelse(search_path);
>  
> -	right_neighbor_of_leaf_node = 0;
> -
> +	
>  	/* With each iteration of this loop we search through the items in the
>  	   current node, and calculate the next current node(next path element)
>  	   for the next iteration of this loop.. */
> @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,	/* Key to s
>  			   starting from the root. */
>  			block_number = SB_ROOT_BLOCK(sb);
>  			expected_level = -1;
> -			right_neighbor_of_leaf_node = 0;
> -
> +			
>  			/* repeat search from the root */
>  			continue;
>  		}
>   

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 06/14/2010 01:48 PM, Nick Bowler wrote:
> On 13:26 Mon 14 Jun     , Justin P. Mattock wrote:
>> @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,	/* Key to s
>>
>>   	pathrelse(search_path);
>>
>> -	right_neighbor_of_leaf_node = 0;
>> -
>> +	
>
> This hunk introduces whitespace on the empty line, which is not cool.

I can resend!!(biggest problem is working
through these warnings)

>
>>   	/* With each iteration of this loop we search through the items in the
>>   	   current node, and calculate the next current node(next path element)
>>   	   for the next iteration of this loop.. */
>> @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,	/* Key to s
>>   			   starting from the root. */
>>   			block_number = SB_ROOT_BLOCK(sb);
>>   			expected_level = -1;
>> -			right_neighbor_of_leaf_node = 0;
>> -
>> +			
>
> Here, too.
>
> Most of the patches in this series have similar issues.
>

main thing now(for me atleast)is,
is this actual dead code or what?
if not then something else needs to
be done, if yes then I guess I can
resend this, with out the whitespace
issue.

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 06/14/2010 02:05 PM, Edward Shishkin wrote:
> Justin P. Mattock wrote:
>> Not sure if this is correct or not.
>> the below patch gets rid of this warning message
>> produced by gcc 4.6.0
>>
>> fs/reiserfs/stree.c: In function 'search_by_key':
>> fs/reiserfs/stree.c:602:6: warning: variable
>> 'right_neighbor_of_leaf_node' set but not used
>>
>> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> Acked-by: Edward Shishkin <edward.shishkin@gmail.com>
>

o.k.!!
what about the whitespace issue?
from what I remember I did notice the "+"
that git does when making patches like this
but given some many of these warnings I just
did a quick workaround or however then figured
to worry later on that.

>> ---
>> fs/reiserfs/stree.c | 7 ++-----
>> 1 files changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c
>> index 313d39d..73086ad 100644
>> --- a/fs/reiserfs/stree.c
>> +++ b/fs/reiserfs/stree.c
>> @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const
>> struct cpu_key *key, /* Key to s
>> struct buffer_head *bh;
>> struct path_element *last_element;
>> int node_level, retval;
>> - int right_neighbor_of_leaf_node;
>> int fs_gen;
>> struct buffer_head *reada_bh[SEARCH_BY_KEY_READA];
>> b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA];
>> @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const
>> struct cpu_key *key, /* Key to s
>>
>> pathrelse(search_path);
>>
>> - right_neighbor_of_leaf_node = 0;
>> -
>> +
>> /* With each iteration of this loop we search through the items in the
>> current node, and calculate the next current node(next path element)
>> for the next iteration of this loop.. */
>> @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const
>> struct cpu_key *key, /* Key to s
>> starting from the root. */
>> block_number = SB_ROOT_BLOCK(sb);
>> expected_level = -1;
>> - right_neighbor_of_leaf_node = 0;
>> -
>> +
>> /* repeat search from the root */
>> continue;
>> }
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Justin P. Mattock wrote:
> On 06/14/2010 02:05 PM, Edward Shishkin wrote:
>> Justin P. Mattock wrote:
>>> Not sure if this is correct or not.
>>> the below patch gets rid of this warning message
>>> produced by gcc 4.6.0
>>>
>>> fs/reiserfs/stree.c: In function 'search_by_key':
>>> fs/reiserfs/stree.c:602:6: warning: variable
>>> 'right_neighbor_of_leaf_node' set but not used
>>>
>>> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>>
>> Acked-by: Edward Shishkin <edward.shishkin@gmail.com>
>>
>
> o.k.!!
> what about the whitespace issue?

Whitespaces should be removed.
I recommend quilt package for managing patches:
"quilt refresh --strip-trailing-whitespace" is your friend..

Thanks,
Edward.

>
> from what I remember I did notice the "+"
> that git does when making patches like this
> but given some many of these warnings I just
> did a quick workaround or however then figured
> to worry later on that.
>
>>> ---
>>> fs/reiserfs/stree.c | 7 ++-----
>>> 1 files changed, 2 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c
>>> index 313d39d..73086ad 100644
>>> --- a/fs/reiserfs/stree.c
>>> +++ b/fs/reiserfs/stree.c
>>> @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const
>>> struct cpu_key *key, /* Key to s
>>> struct buffer_head *bh;
>>> struct path_element *last_element;
>>> int node_level, retval;
>>> - int right_neighbor_of_leaf_node;
>>> int fs_gen;
>>> struct buffer_head *reada_bh[SEARCH_BY_KEY_READA];
>>> b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA];
>>> @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const
>>> struct cpu_key *key, /* Key to s
>>>
>>> pathrelse(search_path);
>>>
>>> - right_neighbor_of_leaf_node = 0;
>>> -
>>> +
>>> /* With each iteration of this loop we search through the items in the
>>> current node, and calculate the next current node(next path element)
>>> for the next iteration of this loop.. */
>>> @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const
>>> struct cpu_key *key, /* Key to s
>>> starting from the root. */
>>> block_number = SB_ROOT_BLOCK(sb);
>>> expected_level = -1;
>>> - right_neighbor_of_leaf_node = 0;
>>> -
>>> +
>>> /* repeat search from the root */
>>> continue;
>>> }
>>
>>
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 06/14/2010 02:47 PM, Edward Shishkin wrote:
> Justin P. Mattock wrote:
>> On 06/14/2010 02:05 PM, Edward Shishkin wrote:
>>> Justin P. Mattock wrote:
>>>> Not sure if this is correct or not.
>>>> the below patch gets rid of this warning message
>>>> produced by gcc 4.6.0
>>>>
>>>> fs/reiserfs/stree.c: In function 'search_by_key':
>>>> fs/reiserfs/stree.c:602:6: warning: variable
>>>> 'right_neighbor_of_leaf_node' set but not used
>>>>
>>>> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>>>
>>> Acked-by: Edward Shishkin <edward.shishkin@gmail.com>
>>>
>>
>> o.k.!!
>> what about the whitespace issue?
>
> Whitespaces should be removed.
> I recommend quilt package for managing patches:
> "quilt refresh --strip-trailing-whitespace" is your friend..
>
> Thanks,
> Edward.
>

o.k. I resent this.. fixed the whitespace(hopefully)
and add your Acked to it.
as for quilt I'll have to look into that..
(using a lfs system, so if the sourcecode is easy
to deal with(build), then it's a good but if it becomes
a nightmare maybe not!!).


Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

On 14 Jun, Justin P. Mattock wrote:
> On 06/14/2010 02:47 PM, Edward Shishkin wrote:
>> Whitespaces should be removed.
>> I recommend quilt package for managing patches:
>> "quilt refresh --strip-trailing-whitespace" is your friend..
> 
> o.k. I resent this.. fixed the whitespace(hopefully)
> and add your Acked to it.
> as for quilt I'll have to look into that..
> (using a lfs system, so if the sourcecode is easy
> to deal with(build), then it's a good but if it becomes
> a nightmare maybe not!!).

Since you appear to generate the patches with git, you can use "git diff
--check [...]" for some basic whitespace checks (additions of trailing
space, additions of space before tab).  For more extensive checks, try
"git diff [...] | scripts/checkpatch.pl -".  Check this before you
commit.  If you committed already, "git commit --amend [-a] [...]" lets
you alter the very last commit of course.
  

On 06/14/2010 04:07 PM, Stefan Richter wrote:
> On 14 Jun, Justin P. Mattock wrote:
>> On 06/14/2010 02:47 PM, Edward Shishkin wrote:
>>> Whitespaces should be removed.
>>> I recommend quilt package for managing patches:
>>> "quilt refresh --strip-trailing-whitespace" is your friend..
>>
>> o.k. I resent this.. fixed the whitespace(hopefully)
>> and add your Acked to it.
>> as for quilt I'll have to look into that..
>> (using a lfs system, so if the sourcecode is easy
>> to deal with(build), then it's a good but if it becomes
>> a nightmare maybe not!!).
>
> Since you appear to generate the patches with git, you can use "git diff
> --check [...]" for some basic whitespace checks (additions of trailing
> space, additions of space before tab).  For more extensive checks, try
> "git diff [...] | scripts/checkpatch.pl -".  Check this before you
> commit.  If you committed already, "git commit --amend [-a] [...]" lets
> you alter the very last commit of course.


Thanks for the info on this, copied it
down in my book of commands...

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html