lkml.org 
[lkml]   [2011]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [patch] Avoid using hardcoded values in kernel/sys.c
On Mon, Oct 17, 2011 at 6:33 PM, David Rientjes <rientjes@google.com> wrote:
>
> Right, I meant to pass the struct in and use sizeof(release->name), but I
> was under the impression that wouldn't count as a variable length array or
> be compiled as such by ISO99 standards because it's a constant expression
> (as the standard says is not variable length).

Yes, if it really were a constant expression of a valid length, that
would be fine. Passing in the struct itself would work, and then you
could do a sizeof of the array, instead of of the pointer to the
character array..

Except in this case it won't work. Because sometimes the struct is the
old one, sometimes it's the new one. So there is no well-defined
struct pointer to pass in. You can only pass in pointer-to-char and
the (variable) size.

Which is why it now just hardcodes it to 65, which is the largest
size. Not exactly "pretty", no. But no worse than using the variable
length array.

Yeah, there are tricks we could play. For example, we could turn that
override_release() into a macro that allocates the array in the
*caller*, where the length is known at compile time, and then pass in
that temporary pointer too. I considered it, but it seemed to be too
much work for too trivial a case. It's not like there are all that
many definitions of utsname, and they are all in <linux/utsname.h>.
It's unlikely that we'd ever add any bigger cases, but if we do, we'd
need to update the constant.

Linus


\
 
 \ /
  Last update: 2011-10-18 03:45    [W:0.281 / U:0.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site