Re: [PATCH] mm: add `const` to lots of pointer parameters

[Max Kellermann <max.kellermann@ionos.com>]

On Thu, Aug 28, 2025 at 2:09 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:

> > 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.

Are you guys talking about making parameter values const (i.e. pointer
addresses if the parameter is a pointer) or making pointed-to values
const?
It seemed Andrew meant the former, but my patch was about the latter.

Yes, making parameters (not pointed-to values) const by default would
be a good default, but we're 50 years late for that, and
unfortunately, C's syntax for pointers with constant address is
awkwardly confusing. But adding "const" to parameter (values, not
pointed-to) should not break anything (unless the function really
changes parameter values - there may be good or bad reasons to do
that).

Making more pointed-to values const will break a lot, yes, because
this needs const-correctness in the whole callee space. This patch
here tries to do this for a low-level part of the kernel, to enable it
in higher-level parts. Long way to go.

Max