[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74a33635-3348-4e70-8cdb-16307f839b79@lucifer.local>
Date: Thu, 28 Aug 2025 13:09:12 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Max Kellermann <max.kellermann@...os.com>, david@...hat.com,
Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org,
surenb@...gle.com, mhocko@...e.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: add `const` to lots of pointer parameters
On Wed, Aug 27, 2025 at 02:48:32PM -0700, Andrew Morton wrote:
> On Wed, 27 Aug 2025 21:22:33 +0200 Max Kellermann <max.kellermann@...os.com> wrote:
>
> > For improved const-correctness.
>
> OK...
>
> >
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -537,7 +537,7 @@ struct address_space {
> > /*
> > * Returns true if any of the pages in the mapping are marked with the tag.
> > */
> > -static inline bool mapping_tagged(struct address_space *mapping, xa_mark_t tag)
> > +static inline bool mapping_tagged(const struct address_space *mapping, xa_mark_t tag)
> > {
> > return xa_marked(&mapping->i_pages, tag);
> > }
>
> I'd actually be in favor of making all incoming args const (C should
> have made this the default).
>
> Because modifying an incoming arg is just obnoxious. That value should
> be viewed as part of the calling environment and should not be altered.
>
> Try modifying a lengthy function and wanting to get at an incoming arg
> only to find that something in the preceding 100 lines has gone and
> messed with it. Or forget to check fr this and get a nasty surprise when
> testing.
>
> Not that I'm suggesting that someone go in and make this change.
>
> On the other hand, it would be neat if gcc had an option to warn when
> someone does this. I bet it would be simple to add.
This would break half the world, I've tried making parameters const, then
finding basically every helper function doesn't function correctly with it
+ having to give up without needing to change half the code base.
It's kind of a dominoes thing at this point.
Broadly I'm in agreement that 'const by default' is good, but there's quite
a big price to pay for this in terms of changes needed for really quite
dubious gains.
I think perhaps 'const if we can moving forward' is better.
Also note that C 'const' is _extremely_ weak. So it's more of a 'readonly
kinda'.
Powered by blists - more mailing lists