> So for statics, I think `static const char *` wins due to allowing
> merging (although it doesn't matter here). For non-statics, you end up
> with extra pointer constants. Those could get removed, but Linux
> doesn't
> have -fvisibility=hidden and I'm not sure how clever linkers are.
> Maybe
>
> So for statics, I think `static const char *` wins due to allowing
> merging (although it doesn't matter here). For non-statics, you end up
> with extra pointer constants. Those could get removed, but Linux
> doesn't
> have -fvisibility=hidden and I'm not sure how clever linkers are.
> Maybe
>
> Thanks for the explanation. I don't think we need to worry about
> merging these strings, but I'll keep it in mind.
>
> However, the "folklore" of the kernel was to never do:
> char *foo = "bar";
> but instead do:
> char foo[] = "bar";
> to save on the extra variable that the
> Thanks for the explanation. I don't think we need to worry about
> merging these strings, but I'll keep it in mind.
>
> However, the "folklore" of the kernel was to never do:
> char *foo = "bar";
> but instead do:
> char foo[] = "bar";
> to save on the extra variable that the
On Thu, Dec 15, 2016 at 03:51:01PM -0500, Daniel Micay wrote:
> > To follow up on this, and after staring at too many outputs of the
> > compiler, I think what this really should be is:
> > static char const critical_overtemp_path[] =
> > "/sbin/critical_overtemp";
> > right?
> >
> > That way
On Thu, Dec 15, 2016 at 03:51:01PM -0500, Daniel Micay wrote:
> > To follow up on this, and after staring at too many outputs of the
> > compiler, I think what this really should be is:
> > static char const critical_overtemp_path[] =
> > "/sbin/critical_overtemp";
> > right?
> >
> > That way
> To follow up on this, and after staring at too many outputs of the
> compiler, I think what this really should be is:
> static char const critical_overtemp_path[] =
> "/sbin/critical_overtemp";
> right?
>
> That way both the variable, and the data, end up in read-only memory
> from what I
> To follow up on this, and after staring at too many outputs of the
> compiler, I think what this really should be is:
> static char const critical_overtemp_path[] =
> "/sbin/critical_overtemp";
> right?
>
> That way both the variable, and the data, end up in read-only memory
> from what I
On Wed, Dec 14, 2016 at 12:54:44PM -0800, Greg KH wrote:
> On Wed, Dec 14, 2016 at 03:29:52PM -0500, Rich Felker wrote:
> > On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote:
> > >
> > > There are a number of usermode helper binaries that are "hard coded" in
> > > the kernel today, so mark
On Wed, Dec 14, 2016 at 12:54:44PM -0800, Greg KH wrote:
> On Wed, Dec 14, 2016 at 03:29:52PM -0500, Rich Felker wrote:
> > On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote:
> > >
> > > There are a number of usermode helper binaries that are "hard coded" in
> > > the kernel today, so mark
On Wed, Dec 14, 2016 at 03:29:52PM -0500, Rich Felker wrote:
> On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote:
> >
> > There are a number of usermode helper binaries that are "hard coded" in
> > the kernel today, so mark them as "const" to make it harder for someone
> > to change where
On Wed, Dec 14, 2016 at 03:29:52PM -0500, Rich Felker wrote:
> On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote:
> >
> > There are a number of usermode helper binaries that are "hard coded" in
> > the kernel today, so mark them as "const" to make it harder for someone
> > to change where
On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote:
>
> There are a number of usermode helper binaries that are "hard coded" in
> the kernel today, so mark them as "const" to make it harder for someone
> to change where the variables point to.
You're not preventing change of where they
On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote:
>
> There are a number of usermode helper binaries that are "hard coded" in
> the kernel today, so mark them as "const" to make it harder for someone
> to change where the variables point to.
You're not preventing change of where they
On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote:
>
> There are a number of usermode helper binaries that are "hard coded" in
> the kernel today, so mark them as "const" to make it harder for someone
> to change where the variables point to.
>
> Signed-off-by: Greg Kroah-Hartman
On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote:
>
> There are a number of usermode helper binaries that are "hard coded" in
> the kernel today, so mark them as "const" to make it harder for someone
> to change where the variables point to.
>
> Signed-off-by: Greg Kroah-Hartman
> ---
>
There are a number of usermode helper binaries that are "hard coded" in
the kernel today, so mark them as "const" to make it harder for someone
to change where the variables point to.
Signed-off-by: Greg Kroah-Hartman
---
drivers/macintosh/windfarm_core.c |
There are a number of usermode helper binaries that are "hard coded" in
the kernel today, so mark them as "const" to make it harder for someone
to change where the variables point to.
Signed-off-by: Greg Kroah-Hartman
---
drivers/macintosh/windfarm_core.c | 2 +-
18 matches
Mail list logo