Re: [PATCH 1/2] ident: stop assuming that `gw_gecos` is writable

[Junio C Hamano <gitster@pobox.com>]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> In 590e081dea7c (ident: add NO_GECOS_IN_PWENT for systems without
> pw_gecos in struct passwd, 2011-05-19), code was introduced to iterate
> over the `gw_gecos` field; The loop variable is of type `char *`, which
> assumes that `gw_gecos` is writable.
>
> However, it is not necessarily writable (and it is a bad idea to have it
> writable in the first place), so let's switch the loop variable type to
> `const char *`.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  ident.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Can we have a bit more details here (not in the commit but after the
three-dash line, meant for context) why the change from 2011 needs a
"hotfix" today?  Has something in the build environment change?  An
updated header file has changed definition for "struct passwd", or
something silly like that?  Even though POSIX.1 does not define
gecos in its struct passwd in <pwd.h>, other string members like
pw_name and pw_dir are writable, which I found funny, and makes me
puzzled why this code from 2011 needs a hotfix all of the sudden.

> diff --git a/ident.c b/ident.c
> index caf41fb2a98..967895d8850 100644
> --- a/ident.c
> +++ b/ident.c
> @@ -59,7 +59,7 @@ static struct passwd *xgetpwuid_self(int *is_bogus)
>  
>  static void copy_gecos(const struct passwd *w, struct strbuf *name)
>  {
> -	char *src;
> +	const char *src;
>  
>  	/* Traditionally GECOS field had office phone numbers etc, separated
>  	 * with commas.  Also & stands for capitalized form of the login name.

The patch text itself looks perfectly fine, so I am not opposed to
its eventual application.  Even though we do declare "src" as
non-const, we only use it to read from it, so declaring it as const
pointer is perfectly fine and more appropriate.

But I do not see any urgency relative to Git 2.48.0 (or Git 2.48.1
for that matter) to mark this as "hotfix" implying that it should be
included in 2.49-rc1 in either the patch or the proposed commit log
message.

Thanks.