Re: [PATCH 1/2] pkt-line: fix declaration of `set_packet_header()`
- Date: Tue, 14 May 2019 14:57:01 +0200 (CEST)
- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
- Subject: Re: [PATCH 1/2] pkt-line: fix declaration of `set_packet_header()`
On Tue, 14 May 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx>
> > From: Johannes Schindelin <johannes.schindelin@xxxxxx>
> > When this function was changed in a97d00799a19 (remote-curl: use
> > post_rpc() for protocol v2 also, 2019-02-21) from file-local to global,
> > the declaration was incorrectly missing the `const` qualifier.
> I do not quite get it. Back when the function was file-scope
> static, it did not even have a separate declaration, and the
> definition the said commit added looks correct to me.
Right, I should have said "the new declaration" instead of "the
> Having "const int size" parameter in the definition of a function
> does help the compilers and the developers by making sure any
> earlier reference to the parameter in the function would not modify
> it and cause later reference to obtain a different value.
> 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"
> 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`,
In any case, I don't think that it makes sense to have a function
declaration whose signature differs from the definition's.
> > -void set_packet_header(char *buf, int size);
> > +void set_packet_header(char *buf, const int size);