From: Andrew Morton <akpm@linux-foundation.org>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Max Kellermann <max.kellermann@ionos.com>,
david@redhat.com, lorenzo.stoakes@oracle.com, vbabka@suse.cz,
rppt@kernel.org, surenb@google.com, mhocko@suse.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: add `const` to lots of pointer parameters
Date: Wed, 27 Aug 2025 19:47:08 -0700 [thread overview]
Message-ID: <20250827194708.a6a87ecae6a992b4c92b6451@linux-foundation.org> (raw)
In-Reply-To: <wmxlcvxqx5qmkzpk6x5fducmmv7giget2nwsvspw3uouufngvs@kxoyppwsyxrv>
On Wed, 27 Aug 2025 21:48:21 -0400 "Liam R. Howlett" <Liam.Howlett@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.
>
> But what of the lazy programmer that just uses the variable at hand
> instead of declaring another one?
Sure, I'd say that's OK for a small function (home-made strcpy) but for
a larger function, expecting other developers to read back through
everything to make sure that Nobody Did That is way unacceptable. It's
laying a trap.
> I also wonder how this would affect inlining choices?
I'd be surprised if the compiler didn't trivially optimize through such
things.
next prev parent reply other threads:[~2025-08-28 2:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-27 19:22 [PATCH] mm: add `const` to lots of pointer parameters Max Kellermann
2025-08-27 21:48 ` Andrew Morton
2025-08-28 1:48 ` Liam R. Howlett
2025-08-28 2:47 ` Andrew Morton [this message]
2025-08-28 12:09 ` Lorenzo Stoakes
2025-08-28 12:16 ` Max Kellermann
2025-08-28 12:35 ` Lorenzo Stoakes
2025-08-28 12:42 ` Max Kellermann
2025-08-28 12:49 ` Lorenzo Stoakes
2025-08-28 12:24 ` Lorenzo Stoakes
2025-08-28 12:28 ` David Hildenbrand
2025-08-28 12:40 ` Max Kellermann
2025-08-28 12:43 ` Lorenzo Stoakes
2025-08-28 12:51 ` Max Kellermann
2025-08-28 13:00 ` David Hildenbrand
2025-08-28 12:55 ` Lorenzo Stoakes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250827194708.a6a87ecae6a992b4c92b6451@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Liam.Howlett@oracle.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=max.kellermann@ionos.com \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.