From: Max Kellermann <max.kellermann@ionos.com>
To: David Hildenbrand <david@redhat.com>
Cc: akpm@linux-foundation.org, axelrasmussen@google.com,
yuanchu@google.com, willy@infradead.org, hughd@google.com,
mhocko@suse.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, lorenzo.stoakes@oracle.com,
Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org,
surenb@google.com, vishal.moola@gmail.com,
linux@armlinux.org.uk, James.Bottomley@hansenpartnership.com,
deller@gmx.de, agordeev@linux.ibm.com,
gerald.schaefer@linux.ibm.com, hca@linux.ibm.com,
gor@linux.ibm.com, borntraeger@linux.ibm.com,
svens@linux.ibm.com, davem@davemloft.net, andreas@gaisler.com,
dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, x86@kernel.org, hpa@zytor.com, chris@zankel.net,
jcmvbkbc@gmail.com, viro@zeniv.linux.org.uk, brauner@kernel.org,
jack@suse.cz, weixugc@google.com, baolin.wang@linux.alibaba.com,
rientjes@google.com, shakeel.butt@linux.dev, thuth@redhat.com,
broonie@kernel.org, osalvador@suse.de, jfalempe@redhat.com,
mpe@ellerman.id.au, nysal@linux.ibm.com,
linux-arm-kernel@lists.infradead.org,
linux-parisc@vger.kernel.org, linux-s390@vger.kernel.org,
sparclinux@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v5 06/12] mm, s390: constify mapping related test functions for improved const-correctness
Date: Mon, 1 Sep 2025 17:22:45 +0200 [thread overview]
Message-ID: <CAKPOu+8SdvDAcNS12TjHWq_QL6pXnw4Pnhrq2_4DgJg8ASc67A@mail.gmail.com> (raw)
In-Reply-To: <0bcb2d4d-9fb5-40c0-ab61-e021277a6ba3@redhat.com>
On Mon, Sep 1, 2025 at 5:11 PM David Hildenbrand <david@redhat.com> wrote:
> >> Should this also be *const ?
> >
> > No. These are function protoypes. A "const" on a parameter value
> > (pointer address, not pointed-to memory) makes no sense on a
> > prototype.
>
> But couldn't you argue the same about variable names? In most (not all
> :) ) we keep declaration + definition in sync. So thus my confusion.
Variable names in the prototypes have no effect either, but they serve
as useful documentation.
Whereas the "const" on a parameter value documents nothing - it's an
implementation detail whether the function would like to modify
parameter values. That implementation detail has no effect for the
caller.
Of course, we could have "const" in the prototype as well. This boils
down to personal taste. It's not my taste (has no use, has no effect,
documents nothing, only adds noise for no gain), so I didn't add it.
If you prefer to have that, I'll leave my taste and home and add it,
but only after you guys make up your minds about whether you want to
have const parameters at all.
next prev parent reply other threads:[~2025-09-01 15:22 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-01 12:30 [PATCH v5 00/12] mm: establish const-correctness for pointer parameters Max Kellermann
2025-09-01 12:30 ` [PATCH v5 01/12] mm: constify shmem related test functions for improved const-correctness Max Kellermann
2025-09-01 13:48 ` David Hildenbrand
2025-09-01 13:58 ` Lorenzo Stoakes
2025-09-01 12:30 ` [PATCH v5 02/12] mm: constify pagemap " Max Kellermann
2025-09-01 13:49 ` David Hildenbrand
2025-09-01 14:39 ` Max Kellermann
2025-09-01 14:09 ` Lorenzo Stoakes
2025-09-01 14:24 ` Lorenzo Stoakes
2025-09-01 14:50 ` Max Kellermann
2025-09-01 15:14 ` Lorenzo Stoakes
2025-09-01 15:47 ` Vlastimil Babka
2025-09-01 15:52 ` David Hildenbrand
2025-09-01 15:55 ` Lorenzo Stoakes
2025-09-01 12:30 ` [PATCH v5 03/12] mm: constify zone " Max Kellermann
2025-09-01 13:50 ` David Hildenbrand
2025-09-01 14:37 ` Lorenzo Stoakes
2025-09-01 12:30 ` [PATCH v5 04/12] fs: constify mapping " Max Kellermann
2025-09-01 13:50 ` David Hildenbrand
2025-09-01 13:51 ` David Hildenbrand
2025-09-01 14:40 ` Lorenzo Stoakes
2025-09-01 12:30 ` [PATCH v5 05/12] mm: constify process_shares_mm() " Max Kellermann
2025-09-01 14:46 ` Lorenzo Stoakes
2025-09-01 12:30 ` [PATCH v5 06/12] mm, s390: constify mapping related test functions " Max Kellermann
2025-09-01 13:54 ` David Hildenbrand
2025-09-01 14:47 ` Lorenzo Stoakes
2025-09-01 15:02 ` Max Kellermann
2025-09-01 15:11 ` David Hildenbrand
2025-09-01 15:22 ` Max Kellermann [this message]
2025-09-01 15:31 ` David Hildenbrand
2025-09-01 12:30 ` [PATCH v5 07/12] parisc: constify mmap_upper_limit() parameter " Max Kellermann
2025-09-01 13:55 ` David Hildenbrand
2025-09-01 14:48 ` Lorenzo Stoakes
2025-09-01 12:30 ` [PATCH v5 08/12] mm: constify arch_pick_mmap_layout() " Max Kellermann
2025-09-01 13:58 ` David Hildenbrand
2025-09-01 14:49 ` Lorenzo Stoakes
2025-09-01 15:06 ` Max Kellermann
2025-09-01 12:30 ` [PATCH v5 09/12] mm: constify ptdesc_pmd_pts_count() and folio_get_private() Max Kellermann
2025-09-01 13:58 ` David Hildenbrand
2025-09-01 14:50 ` Lorenzo Stoakes
2025-09-01 12:30 ` [PATCH v5 10/12] mm: constify various inline test functions for improved const-correctness Max Kellermann
2025-09-01 14:00 ` David Hildenbrand
2025-09-01 15:13 ` Max Kellermann
2025-09-01 12:30 ` [PATCH v5 11/12] mm: constify assert/test functions in mm.h Max Kellermann
2025-09-01 14:06 ` David Hildenbrand
2025-09-01 15:17 ` Max Kellermann
2025-09-01 15:25 ` David Hildenbrand
2025-09-01 12:30 ` [PATCH v5 12/12] mm: constify highmem related functions for improved const-correctness Max Kellermann
2025-09-01 14:51 ` Lorenzo Stoakes
2025-09-01 13:44 ` [PATCH v5 00/12] mm: establish const-correctness for pointer parameters Christian Brauner
2025-09-01 14:32 ` Lorenzo Stoakes
2025-09-02 2:50 ` Matthew Wilcox
2025-09-02 8:15 ` David Hildenbrand
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=CAKPOu+8SdvDAcNS12TjHWq_QL6pXnw4Pnhrq2_4DgJg8ASc67A@mail.gmail.com \
--to=max.kellermann@ionos.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=Liam.Howlett@oracle.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=axelrasmussen@google.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=brauner@kernel.org \
--cc=broonie@kernel.org \
--cc=chris@zankel.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=deller@gmx.de \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=jcmvbkbc@gmail.com \
--cc=jfalempe@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lorenzo.stoakes@oracle.com \
--cc=luto@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=nysal@linux.ibm.com \
--cc=osalvador@suse.de \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=sparclinux@vger.kernel.org \
--cc=surenb@google.com \
--cc=svens@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=thuth@redhat.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=vishal.moola@gmail.com \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=yuanchu@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).