From: Jeff King <firstname.lastname@example.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <email@example.com>,
Johannes Schindelin via GitGitGadget <firstname.lastname@example.org>,
Subject: Re: [PATCH 1/2] pkt-line: fix declaration of `set_packet_header()`
Date: Tue, 14 May 2019 10:43:06 -0400 [thread overview]
Message-ID: <20190514144305.GA28530@sigill.intra.peff.net> (raw)
On Tue, May 14, 2019 at 02:57:01PM +0200, Johannes Schindelin wrote:
> > But the parameter treated as a constant without getting modified
> > during the invocation of the function is an implementation detail of
> > the function; there is no point exposing that implementation detail
> > to its callers. It does not even help the compilers handling the
> > caller's compilation unit---the parameter is passed by value, so the
> > caller knows that the callee would not modify it without "const"
> > there.
> > Does the language even allow flagging "const int in the definition,
> > int in the declaration" as a warning-worthy discrepancy?
> Apparently it does, as MS Visual C does issue a warning (and with `/Wall`,
> it fails).
> In any case, I don't think that it makes sense to have a function
> declaration whose signature differs from the definition's.
I actually agree with Junio's point that in an ideal world the
declaration should omit details that are not relevant to the caller. But
clearly we do not live in that world, and this is a small enough point
that we should fix it in one direction or the other.
I do have a slight preference for going the _other_ way. There is no
need to mark the parameter as const in the definition. It is passed by
value, so nobody except the function body cares either way. And we have
many function bodies where value-passed parameters (or local variables!)
are not marked as const, even though they are only assigned to once.
I don't think that annotation is telling much to any reader of the code,
nor to a decent optimizing compiler.
next prev parent reply other threads:[~2019-05-14 14:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-13 22:43 [PATCH 0/2] pkt-line: fix incorrect function declaration Johannes Schindelin via GitGitGadget
2019-05-13 22:43 ` [PATCH 1/2] pkt-line: fix declaration of `set_packet_header()` Johannes Schindelin via GitGitGadget
2019-05-13 23:24 ` Junio C Hamano
2019-05-14 12:57 ` Johannes Schindelin
2019-05-14 14:43 ` Jeff King [this message]
2019-05-14 14:44 ` Jeff King
2019-05-15 1:42 ` Junio C Hamano
2019-05-15 1:44 ` Jeff King
2019-05-15 10:39 ` Johannes Schindelin
2019-05-16 2:24 ` Junio C Hamano
2019-05-16 3:42 ` Jeff King
2019-05-16 4:28 ` Junio C Hamano
2019-05-17 18:54 ` Johannes Schindelin
2019-05-13 22:43 ` [PATCH 2/2] parse-options: adjust `parse_opt_unknown_cb()`s declared return type Johannes Schindelin via GitGitGadget
2019-05-13 23:29 ` Junio C Hamano
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
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 read-only IMAP folder(s) and NNTP newsgroup(s).