git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH v2 2/4] do full type check in BARF_UNLESS_COPYABLE
Date: Sun, 8 Jan 2023 11:10:59 +0100	[thread overview]
Message-ID: <3e04e283-cad0-7be4-d85c-65d0a52289e2@web.de> (raw)
In-Reply-To: <xmqqy1qdxz67.fsf@gitster.g>

Am 08.01.2023 um 08:28 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
>
>> Use __builtin_types_compatible_p to perform a full type check if
>> possible.  Otherwise fall back to the old size comparison, but add a
>> non-evaluated assignment to catch more type mismatches.  It doesn't flag
>> copies between arrays with different signedness, but that's as close to
>> a full type check as it gets without the builtin, as far as I can see.
>
> This seems to unfortunately break builds for compat/mingw.c
>
> cf. https://github.com/git/git/actions/runs/3865788736/jobs/6589504628#step:4:374
>
>    1848 |                 COPY_ARRAY(&argv2[1], &argv[1], argc);
>
> where the two arrays are "char *const *argv" in the parameter list, and
> a local variable
>
> #ifndef _MSC_VER
> 		const
> #endif
> 		char **argv2;
>
> It seems that (const char **) and (char **) are compatible but the
> pointers themselves being const breaks the type compatibility?
> Perhaps the latter should be "(optionally const) char *const *argv2"?

We compare the types of the elements, so effectively we do this:

   __builtin_types_compatible_p(__typeof__(const char *),  __typeof__(char *))

... which returns 0.

We can remove the const like we already do for Visual Studio.  But
then we have to add two casts when passing on argv2, like in
mingw_execv(), because adding a const to a pointer of a pointer
must be done explicitly in C (even though Visual Studio seems to
do it implicitly without complaining).  Feels a bit silly. :-|

--- >8 ---
Subject: [PATCH 1.5/4] mingw: make argv2 in try_shell_exec() non-const

Prepare for a stricter type check in COPY_ARRAY by removing the const
qualifier of argv2, like we already do to placate Visual Studio.  We
have to add it back using explicit casts when actually using the
variable, unfortunately, because GCC (rightly) refuses to add it
implicitly.  Similar casts are already used in mingw_execv().

Signed-off-by: René Scharfe <l.s.r@web.de>
---
 compat/mingw.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/compat/mingw.c b/compat/mingw.c
index d614f156df..e131eb9b07 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1839,16 +1839,13 @@ static int try_shell_exec(const char *cmd, char *const *argv)
 	if (prog) {
 		int exec_id;
 		int argc = 0;
-#ifndef _MSC_VER
-		const
-#endif
 		char **argv2;
 		while (argv[argc]) argc++;
 		ALLOC_ARRAY(argv2, argc + 1);
 		argv2[0] = (char *)cmd;	/* full path to the script file */
 		COPY_ARRAY(&argv2[1], &argv[1], argc);
-		exec_id = trace2_exec(prog, argv2);
-		pid = mingw_spawnv(prog, argv2, 1);
+		exec_id = trace2_exec(prog, (const char **)argv2);
+		pid = mingw_spawnv(prog, (const char **)argv2, 1);
 		if (pid >= 0) {
 			int status;
 			if (waitpid(pid, &status, 0) < 0)
--
2.38.1.windows.1

  reply	other threads:[~2023-01-08 10:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30 21:51 [PATCH 0/3] COPY_ARRAY, MOVE_ARRAY, DUP_ARRAY René Scharfe
2022-12-30 21:56 ` [PATCH 1/3] do full type check in COPY_ARRAY and MOVE_ARRAY René Scharfe
2023-01-01  3:03   ` Junio C Hamano
2023-01-01  3:59     ` Junio C Hamano
2023-01-01  7:41       ` René Scharfe
2023-01-01 10:45         ` René Scharfe
2023-01-01 12:11           ` Junio C Hamano
2023-01-01 12:32             ` René Scharfe
2023-01-01 12:46               ` Junio C Hamano
2022-12-30 22:02 ` [PATCH 2/3] add DUP_ARRAY René Scharfe
2022-12-30 22:03 ` [PATCH 3/3] use DUP_ARRAY René Scharfe
2023-01-01 21:05 ` [PATCH v2 0/4] COPY_ARRAY, MOVE_ARRAY, DUP_ARRAY René Scharfe
2023-01-01 21:08   ` [PATCH v2 1/4] factor out BARF_UNLESS_COPYABLE René Scharfe
2023-01-01 21:11   ` [PATCH v2 2/4] do full type check in BARF_UNLESS_COPYABLE René Scharfe
2023-01-08  7:28     ` Junio C Hamano
2023-01-08 10:10       ` René Scharfe [this message]
2023-01-09  4:27         ` Junio C Hamano
2023-01-09 18:08           ` Jeff Hostetler
2023-01-01 21:14   ` [PATCH v2 3/4] add DUP_ARRAY René Scharfe
2023-01-01 21:16   ` [PATCH v2 4/4] use DUP_ARRAY René Scharfe

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=3e04e283-cad0-7be4-d85c-65d0a52289e2@web.de \
    --to=l.s.r@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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).