Quoting Dan Smith (danms@xxxxxxxxxx): > 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 <danms@xxxxxxxxxx> > Cc: containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > Cc: akpm@xxxxxxxxxxxxxxxxxxxx > Cc: serue@xxxxxxxxxx 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 <serue@xxxxxxxxxx> 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
