[PATCH] 2.6.35.4: Fixed simple warning (array subscript is above array bounds)

[PATCH] 2.6.35.4: Fixed simple warning (array subscript is above array bounds)

[Poyo VL]

From: Ionut Gabriel Popescu <poyo_vl@yahoo.com>

When I tried to compile, I got the following warning:
fs/xfs/xfs_dir2_block.c: In function ‘xfs_dir2_sf_to_block’:
fs/xfs/xfs_dir2_block.c:1153:26: warning: array subscript is above array bounds
The code (fs/xfs/xfs_dir2_block.c line 1153) is:
dep->name[0] = dep->name[1] = '.';
dep is a pointer to a xfs_dir2_data_entry_t structure where name is defined as:
__u8            name[1];    /* name bytes, no null */
So it is a single element array, name[0] not also name[1] so I got that warning.
Patching is a simple replacement of 1 with 2.

Signed-off-by: Ionut Gabriel Popescu <poyo_vl@yahoo.com>
---

--- a/fs/xfs/xfs_dir2_data.h    2010-09-02 11:13:11.632007536 +0300
+++ b/fs/xfs/xfs_dir2_data.h    2010-09-02 11:13:28.080006488 +0300
@@ -87,7 +87,7 @@
 typedef struct xfs_dir2_data_entry {
     __be64            inumber;    /* inode number */
     __u8            namelen;    /* name length */
-    __u8            name[1];    /* name bytes, no null */
+    __u8            name[2];    /* name bytes, no null */
                         /* variable offset */
     __be16            tag;        /* starting offset of us */
 } xfs_dir2_data_entry_t;


      

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

Re: [PATCH] 2.6.35.4: Fixed simple warning (array subscript is above array bounds)

[Alex Elder]

On Thu, 2010-09-02 at 02:10 -0700, Poyo VL wrote:
> From: Ionut Gabriel Popescu <poyo_vl@yahoo.com>
> 
> When I tried to compile, I got the following warning:
> fs/xfs/xfs_dir2_block.c: In function ‘xfs_dir2_sf_to_block’:
> fs/xfs/xfs_dir2_block.c:1153:26: warning: array subscript is above array bounds
> The code (fs/xfs/xfs_dir2_block.c line 1153) is:
> dep->name[0] = dep->name[1] = '.';
> dep is a pointer to a xfs_dir2_data_entry_t structure where name is defined as:
> __u8            name[1];    /* name bytes, no null */
> So it is a single element array, name[0] not also name[1] so I got that warning.
> Patching is a simple replacement of 1 with 2.

It looks to me like this will work.  But I would like
a second opinion on that before I commit this change.

An xfs_dir2_data_entry structure is defined the way
it is to be informative; its physical representation
is different when it's actually used.  The name array
is sized based on the actual name length, and the tag
lies somewhere after that--at the very end of the
(dynamically-sized) data entry.

Additionally, the alignment of the overall structure
will be 64 bits because of hte inumber field.  Expanding
the name field by another byte will not change that.

So I think this change is OK.  Can anyone else
back me up?

Reviewed-by: Alex Elder <aelder@sgi.com>

> Signed-off-by: Ionut Gabriel Popescu <poyo_vl@yahoo.com>
> ---
> 
> --- a/fs/xfs/xfs_dir2_data.h    2010-09-02 11:13:11.632007536 +0300
> +++ b/fs/xfs/xfs_dir2_data.h    2010-09-02 11:13:28.080006488 +0300
> @@ -87,7 +87,7 @@
>  typedef struct xfs_dir2_data_entry {
>      __be64            inumber;    /* inode number */
>      __u8            namelen;    /* name length */
> -    __u8            name[1];    /* name bytes, no null */
> +    __u8            name[2];    /* name bytes, no null */
>                          /* variable offset */
>      __be16            tag;        /* starting offset of us */
>  } xfs_dir2_data_entry_t;
> 
> 
>       



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

Re: [PATCH] 2.6.35.4: Fixed simple warning (array subscript is above array bounds)

[Christoph Hellwig]

On Thu, Sep 16, 2010 at 11:42:02AM -0500, Alex Elder wrote:
> Additionally, the alignment of the overall structure
> will be 64 bits because of hte inumber field.  Expanding
> the name field by another byte will not change that.
> 
> So I think this change is OK.  Can anyone else
> back me up?

We do sizeof requests on a few of these structures, not sure if it
includes this one.  I have a patchset to dust off that gets rid of
all the structures that aren't actually physically on disk.  I'll
try to dust if off and submit it - this was a preparation for the
CRC enablement of the directory structures.

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