git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	Alex Riesen <raa.lkml@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v2] for_each_string_list_item: avoid undefined behavior for empty list
Date: Wed, 20 Sep 2017 14:40:32 +0900	[thread overview]
Message-ID: <xmqqbmm6nd0v.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20170920052705.GC126984@aiede.mtv.corp.google.com> (Jonathan Nieder's message of "Tue, 19 Sep 2017 22:27:05 -0700")

Jonathan Nieder <jrnieder@gmail.com> writes:

> D. Eliminate for_each_string_list_item and let callers just do
>
> 	unsigned int i;
> 	for (i = 0; i < list->nr; i++) {
> 		struct string_list_item *item = list->items[i];
> 		...
> 	}
>
>    Having to declare item is unnecessarily verbose, decreasing the
>    appeal of this option.  I think I like it anyway, but I wasn't able
>    to convince coccinelle to do it.

When using the macro, item still needs to be declared outside by the
user, so it's not all that unpleasant, though.

> E. Use subtraction instead of addition:
>    #define for_each_string_list_item(item, list) \
>    	for (item = ...; \
> 	     (item == list->items ? 0 : item - list->items) < nr; \
> 	     item++)
>
>    I expected the compiler to figure out that this is a long way of writing
>    (item - list->items), but at least with gcc 4.8.4 -O2, no such
>    luck.  This generates uglier assembly than the NULL check.

Yuck.  You cannot easily unsee such an ugliness X-<.

The patch and explanation above --- looked quite nicely written.
Will queue.

Thanks.

> diff --git a/string-list.h b/string-list.h
> index 29bfb7ae45..79ae567cbc 100644
> --- a/string-list.h
> +++ b/string-list.h
> @@ -32,8 +32,10 @@ void string_list_clear_func(struct string_list *list, string_list_clear_func_t c
>  typedef int (*string_list_each_func_t)(struct string_list_item *, void *);
>  int for_each_string_list(struct string_list *list,
>  			 string_list_each_func_t, void *cb_data);
> -#define for_each_string_list_item(item,list) \
> -	for (item = (list)->items; item < (list)->items + (list)->nr; ++item)
> +#define for_each_string_list_item(item,list)            \
> +	for (item = (list)->items;                      \
> +	     item && item < (list)->items + (list)->nr; \
> +	     ++item)
>  
>  /*
>   * Apply want to each item in list, retaining only the ones for which

  reply	other threads:[~2017-09-20  5:40 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-15 16:00 [PATCH] for_each_string_list_item(): behave correctly for empty list Michael Haggerty
2017-09-15 18:43 ` Jonathan Nieder
2017-09-16  4:06   ` Michael Haggerty
2017-09-16 11:51     ` SZEDER Gábor
2017-09-17 10:19       ` Michael Haggerty
2017-09-19 14:38     ` Kaartic Sivaraam
2017-09-20  1:38       ` Junio C Hamano
2017-09-20  1:43         ` Jonathan Nieder
2017-09-20  5:14           ` Junio C Hamano
2017-09-20  2:30       ` Jonathan Nieder
2017-09-20  3:54         ` Junio C Hamano
2017-09-20  5:27           ` [PATCH v2] for_each_string_list_item: avoid undefined behavior " Jonathan Nieder
2017-09-20  5:40             ` Junio C Hamano [this message]
2017-09-20  7:00             ` Michael Haggerty
2017-09-20  7:40             ` Kaartic Sivaraam
2017-09-20 12:22             ` [PATCH v2] doc: camelCase the config variables to improve readability Kaartic Sivaraam
2017-09-20 16:28             ` [PATCH v2] for_each_string_list_item: avoid undefined behavior for empty list Andreas Schwab
2017-09-20 17:31               ` Jonathan Nieder
2017-09-20 21:51                 ` Andreas Schwab
2017-09-21  1:12                   ` Junio C Hamano
2017-09-21 15:39                     ` Andreas Schwab
2017-09-20  7:35         ` [PATCH] for_each_string_list_item(): behave correctly " Kaartic Sivaraam
2017-09-17  0:59 ` Junio C Hamano
2017-09-17 10:24   ` Michael Haggerty
2017-09-18  0:37     ` Junio C Hamano
2017-09-19  0:08       ` Stefan Beller
2017-09-19  6:51         ` Michael Haggerty
2017-09-19 13:38           ` SZEDER Gábor
2017-09-19 13:45             ` SZEDER Gábor

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqbmm6nd0v.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=kaarticsivaraam91196@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --cc=raa.lkml@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).