All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.