git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Sören Krecker" <soekkle@freenet.de>
Cc: git@vger.kernel.org,  tboegi@web.de,  phillip.wood@dunelm.org.uk
Subject: Re: [PATCH v2 1/1] [PATCH] mimgw: remove Compiler Warnings
Date: Wed, 09 Oct 2024 11:20:45 -0700	[thread overview]
Message-ID: <xmqq4j5lt9xe.fsf@gitster.g> (raw)
In-Reply-To: <20241009171342.2354-2-soekkle@freenet.de> ("Sören Krecker"'s message of "Wed, 9 Oct 2024 19:13:42 +0200")

Sören Krecker <soekkle@freenet.de> writes:

> Remove some compiler warnings from msvc in compat/mingw.c for value truncation from 64 bit to 32 bit intigers.

An overly long line?

> diff --git a/compat/mingw.c b/compat/mingw.c
> index 0e851ecae2..5293f4cdae 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -782,7 +782,7 @@ static inline void filetime_to_timespec(const FILETIME *ft, struct timespec *ts)
>   */
>  static int has_valid_directory_prefix(wchar_t *wfilename)
>  {
> -	int n = wcslen(wfilename);
> +	ssize_t n = wcslen(wfilename); /*can become negative*/

Aside from the malformed comment ("/* can become negative */" with
spaces would have been OK), I am not sure where it can become
negative, unless wcslen() is allowed to return a negative value to
signal some kind of error (in which case, the comment should say
that), which is not the case.

The loop body in the post-context of this hunk looks like

>  	while (n > 0) {
>  		wchar_t c = wfilename[--n];
		... 'n' is not written anywhere else in this loop ...
	}

so an 'n' that is not negative before entering the loop can never
become negative by what the loop body does.

> @@ -891,7 +891,7 @@ static int do_lstat(int follow, const char *file_name, struct stat *buf)
>   */
>  static int do_stat_internal(int follow, const char *file_name, struct stat *buf)
>  {
> -	int namelen;
> +	size_t namelen; /* contains length of a string*/

Indeed, this receives the return value of strlen().  I am not sure
if this comment is necessary, though.  Just like you omitted any
comment on size_t variables that receives .len in a strbuf, its
correctness is rather obvious.

> @@ -1274,7 +1274,8 @@ static const char *parse_interpreter(const char *cmd)
>  {
>  	static char buf[100];
>  	char *p, *opt;
> -	int n, fd;
> +	ssize_t n; /* read() can return negativ values */

The word is "negative".

But 'n' is also used to receive the result of strlen().  A kosher
rewrite may be to split it into two separate variables, 

	size_t cmdlen = strlen(cmd);
	ssize_t bytes_read = read(fd, buf, sizeof(buf)-1);

> @@ -1956,7 +1957,7 @@ char *mingw_getenv(const char *name)
>  #define GETENV_MAX_RETAIN 64
>  	static char *values[GETENV_MAX_RETAIN];
>  	static int value_counter;
> -	int len_key, len_value;
> +	size_t len_key, len_value; /* lengt of strings */

"length".

Again given "size_t strlen(const char *)", this may be sufficiently
obvious.

> @@ -2001,7 +2004,7 @@ char *mingw_getenv(const char *name)
>  
>  int mingw_putenv(const char *namevalue)
>  {
> -	int size;
> +	size_t size; /* lengt of a string */

Ditto.

> @@ -3085,7 +3089,8 @@ static void maybe_redirect_std_handles(void)
>   */
>  int wmain(int argc, const wchar_t **wargv)
>  {
> -	int i, maxlen, exit_status;
> +	int i, exit_status;
> +	size_t maxlen; /*contains length os arguments*/

Missing SP around the words.

Again, given "size_t wcslen(const wchar_t *)", it may be obvious to
readers.

> diff --git a/compat/vcbuild/include/unistd.h b/compat/vcbuild/include/unistd.h
> ...
> +#ifdef _WIN64
> +typedef __int64 _ssize_t;
> +#else
>  typedef long _ssize_t;
> +#endif // _AMD64

It is a bit unusual that "#ifdef X" is not closed with "#endif /* X */".
Some folks write "#endif /* !X */" but what I am wondering about is
a mismatch between _WIN64 and _AMD64.



  reply	other threads:[~2024-10-09 18:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09 10:35 [PATCH] mimgw: remove Compiler Warnings Sören Krecker
2024-10-09 15:26 ` Torsten Bögershausen
2024-10-09 16:13 ` Phillip Wood
2024-10-09 17:13   ` Sören Krecker
2024-10-09 17:13     ` [PATCH v2 1/1] " Sören Krecker
2024-10-09 18:20       ` Junio C Hamano [this message]
2024-10-10  8:59       ` Phillip Wood
2024-10-10 10:29         ` [PATCH] [PATCH] mimgw: Remove " Sören Krecker
2024-10-10 19:19           ` Torsten Bögershausen
2024-10-12  6:22             ` [PATCH v4] mingw.c: Fix complier warnings for a 64 bit msvc Sören Krecker
2024-10-16 16:51               ` Torsten Bögershausen
2024-10-16 20:22               ` Taylor Blau
2024-10-17 17:18                 ` [PATCH v5 0/1] " Sören Krecker
2024-10-17 17:18                   ` [PATCH 1/1] [PATCH] " Sören Krecker
2024-10-17 18:43                     ` Taylor Blau
2024-10-10 16:08         ` [PATCH v2 1/1] [PATCH] mimgw: remove Compiler Warnings Junio C Hamano

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=xmqq4j5lt9xe.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=soekkle@freenet.de \
    --cc=tboegi@web.de \
    /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).