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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250827194708.a6a87ecae6a992b4c92b6451@linux-foundation.org>
Date: Wed, 27 Aug 2025 19:47:08 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>
Cc: Max Kellermann <max.kellermann@...os.com>, david@...hat.com,
 lorenzo.stoakes@...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, 27 Aug 2025 21:48:21 -0400 "Liam R. Howlett" <Liam.Howlett@...cle.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.