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: <56d18767-8b3e-470d-ad60-781a6f17f9d4@lucifer.local>
Date: Thu, 28 Aug 2025 13:35:19 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Max Kellermann <max.kellermann@...os.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 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 Thu, Aug 28, 2025 at 02:16:42PM +0200, Max Kellermann wrote:
> On Thu, Aug 28, 2025 at 2:09 PM Lorenzo Stoakes
> <lorenzo.stoakes@...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.
> >
> > 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

I'm talking about const parameter values.

I gave a more full reply in general to this at top-level.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ