2009-04-17 17:51:20

by Dan Smith

[permalink] [raw]
Subject: [PATCH] Make new_utsname fields use the proper length constant

The members of the new_utsname structure are defined with magic numbers
that *should* correspond to the constant __NEW_UTS_LEN+1. Everywhere else,
code assumes this and uses the constant, so this patch makes the structure
match.

Originally suggested by Serge here:

https://lists.linux-foundation.org/pipermail/containers/2009-March/016258.html

Signed-off-by: Dan Smith <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
include/linux/utsname.h | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/utsname.h b/include/linux/utsname.h
index 1123267..3656b30 100644
--- a/include/linux/utsname.h
+++ b/include/linux/utsname.h
@@ -22,12 +22,12 @@ struct old_utsname {
};

struct new_utsname {
- char sysname[65];
- char nodename[65];
- char release[65];
- char version[65];
- char machine[65];
- char domainname[65];
+ char sysname[__NEW_UTS_LEN + 1];
+ char nodename[__NEW_UTS_LEN + 1];
+ char release[__NEW_UTS_LEN + 1];
+ char version[__NEW_UTS_LEN + 1];
+ char machine[__NEW_UTS_LEN + 1];
+ char domainname[__NEW_UTS_LEN + 1];
};

#ifdef __KERNEL__
--
1.5.6.3


2009-04-17 18:06:39

by Serge E. Hallyn

[permalink] [raw]
Subject: Re: [PATCH] Make new_utsname fields use the proper length constant

Quoting Dan Smith ([email protected]):
> The members of the new_utsname structure are defined with magic numbers
> that *should* correspond to the constant __NEW_UTS_LEN+1. Everywhere else,
> code assumes this and uses the constant, so this patch makes the structure
> match.
>
> Originally suggested by Serge here:
>
> https://lists.linux-foundation.org/pipermail/containers/2009-March/016258.html
>
> Signed-off-by: Dan Smith <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]

I realize it's weird putting __NEW_UTS_LEN+1 in the
length for struct old_utsname :), but you didn't make
up the names, so I would argue just do it for both
old_utsname and oldold_utsname too...

But of course even if you don't want to,

Acked-by: Serge Hallyn <[email protected]>

thanks, Dan.

-serge

> ---
> include/linux/utsname.h | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/utsname.h b/include/linux/utsname.h
> index 1123267..3656b30 100644
> --- a/include/linux/utsname.h
> +++ b/include/linux/utsname.h
> @@ -22,12 +22,12 @@ struct old_utsname {
> };
>
> struct new_utsname {
> - char sysname[65];
> - char nodename[65];
> - char release[65];
> - char version[65];
> - char machine[65];
> - char domainname[65];
> + char sysname[__NEW_UTS_LEN + 1];
> + char nodename[__NEW_UTS_LEN + 1];
> + char release[__NEW_UTS_LEN + 1];
> + char version[__NEW_UTS_LEN + 1];
> + char machine[__NEW_UTS_LEN + 1];
> + char domainname[__NEW_UTS_LEN + 1];
> };
>
> #ifdef __KERNEL__
> --
> 1.5.6.3