git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "René Scharfe" <l.s.r@web.de>
Cc: Vegard Nossum <vegard.nossum@oracle.com>,
	Lars Schneider <larsxschneider@gmail.com>,
	Junio C Hamano <gitster@pobox.com>,
	allan.x.xavier@oracle.com,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH v1] Travis: also test on 32-bit Linux
Date: Fri, 10 Mar 2017 02:45:58 -0500	[thread overview]
Message-ID: <20170310074558.ifse3omthmtih73l@sigill.intra.peff.net> (raw)
In-Reply-To: <63a6ec61-653d-6307-4739-2ebaa8dbde35@web.de>

On Fri, Mar 10, 2017 at 01:14:45AM +0100, René Scharfe wrote:

> >   3. There were a number of alloc-and-copy instances. The copy part is
> >      the same as (2) above, but you have to repeat the size, which is
> >      potentially error-prone. I wonder if we would want something like:
> > 
> >        #define ALLOC_COPY(dst, src) do { \
> >          (dst) = xmalloc(sizeof(*(dst))); \
> > 	 COPY_ARRAY(dst, src, 1); \
> >        while(0)
> > 
> >      That avoids having to specify the size at all, and triggers a
> >      compile-time error if "src" and "dst" point to objects of different
> >      sizes.
> 
> Or you could call it DUP or similar.  And you could use ALLOC_ARRAY in
> its definition and let it infer the size implicitly (don't worry too
> much about the multiplication with one):
> 
> 	#define DUPLICATE_ARRAY(dst, src, n) do {	\
> 		ALLOC_ARRAY((dst), (n));		\
> 		COPY_ARRAY((dst), (src), (n));		\
> 	} while (0)
> 	#define DUPLICATE(dst, src) DUPLICATE_ARRAY((dst), (src), 1)
> 
> But do we even want such a thing?  Duplicating objects should be rare, and
> keeping allocation and assignment/copying separate makes for more flexible
> building blocks.  Adding ALLOC (and CALLOC) for single objects could be more
> widely useful, I think.

There's no reason you can't have both the building blocks and the thing
that is built for them. I think there are 5 spots that would use
DUPLICATE(), but I agree that there are more which could use ALLOC().

I'd be more worried that we're slowly drifting away from idiomatic C.
If it's safer, that's good. But if it makes it hard for people new to
the project to figure out what the hell is going on, that may be not so
good.

Here's the list of DUPLICATE spots, for reference.

---
diff --git a/builtin/blame.c b/builtin/blame.c
index f7aa95f4b..f0ac1c511 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -661,8 +661,8 @@ static struct origin *find_rename(struct scoreboard *sb,
 static void add_blame_entry(struct blame_entry ***queue,
 			    const struct blame_entry *src)
 {
-	struct blame_entry *e = xmalloc(sizeof(*e));
-	memcpy(e, src, sizeof(*e));
+	struct blame_entry *e;
+	DUPLICATE(e, src);
 	origin_incref(e->suspect);
 
 	e->next = **queue;
diff --git a/builtin/pack-redundant.c b/builtin/pack-redundant.c
index 72c815844..d6cb893cf 100644
--- a/builtin/pack-redundant.c
+++ b/builtin/pack-redundant.c
@@ -206,8 +206,8 @@ static void llist_sorted_difference_inplace(struct llist *A,
 static inline struct pack_list * pack_list_insert(struct pack_list **pl,
 					   struct pack_list *entry)
 {
-	struct pack_list *p = xmalloc(sizeof(struct pack_list));
-	memcpy(p, entry, sizeof(struct pack_list));
+	struct pack_list *p;
+	DUPLICATE(p, entry);
 	p->next = *pl;
 	*pl = p;
 	return p;
@@ -238,8 +238,7 @@ static struct pack_list * pack_list_difference(const struct pack_list *A,
 			return pack_list_difference(A->next, B);
 		pl = pl->next;
 	}
-	ret = xmalloc(sizeof(struct pack_list));
-	memcpy(ret, A, sizeof(struct pack_list));
+	DUPLICATE(ret, A);
 	ret->next = pack_list_difference(A->next, B);
 	return ret;
 }
@@ -450,8 +449,7 @@ static void minimize(struct pack_list **min)
 		perm_all = perm = get_permutations(non_unique, n);
 		while (perm) {
 			if (is_superset(perm->pl, missing)) {
-				new_perm = xmalloc(sizeof(struct pll));
-				memcpy(new_perm, perm, sizeof(struct pll));
+				DUPLICATE(new_perm, perm);
 				new_perm->next = perm_ok;
 				perm_ok = new_perm;
 			}
diff --git a/diff.c b/diff.c
index 051761be4..dfe02f403 100644
--- a/diff.c
+++ b/diff.c
@@ -1168,8 +1168,8 @@ static void init_diff_words_data(struct emit_callback *ecbdata,
 				 struct diff_filespec *two)
 {
 	int i;
-	struct diff_options *o = xmalloc(sizeof(struct diff_options));
-	memcpy(o, orig_opts, sizeof(struct diff_options));
+	struct diff_options *o;
+	DUPLICATE(o, orig_opts);
 
 	ecbdata->diff_words =
 		xcalloc(1, sizeof(struct diff_words_data));

  reply	other threads:[~2017-03-10  7:46 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28 19:17 [PATCH] Travis: also test on 32-bit Linux Johannes Schindelin
2017-02-28 20:34 ` Johannes Schindelin
2017-03-02  5:06 ` Junio C Hamano
2017-03-02 10:51 ` [PATCH v1] " Lars Schneider
2017-03-02 11:24   ` Johannes Schindelin
2017-03-02 11:38     ` Lars Schneider
2017-03-02 14:22       ` Johannes Schindelin
2017-03-02 15:53         ` Christian Couder
2017-03-02 18:03       ` Junio C Hamano
2017-03-03  2:17         ` Johannes Schindelin
2017-03-03 18:43           ` Junio C Hamano
2017-03-04  0:03             ` Junio C Hamano
2017-03-04  4:11               ` Junio C Hamano
2017-03-04 17:23                 ` Lars Schneider
2017-03-04 18:08                   ` Vegard Nossum
2017-03-04 19:49                     ` Vegard Nossum
2017-03-04 20:08                       ` Vegard Nossum
2017-03-05 11:36                         ` Jeff King
2017-03-05 11:44                           ` [PATCH] line-log: use COPY_ARRAY to fix mis-sized memcpy Jeff King
2017-03-05 12:20                             ` Vegard Nossum
2017-03-05 11:46                           ` [PATCH v1] Travis: also test on 32-bit Linux Jeff King
2017-03-10  0:14                           ` René Scharfe
2017-03-10  8:18                             ` Jeff King
2017-03-10 16:20                               ` René Scharfe
2017-03-10 17:57                                 ` Jeff King
2017-03-10 18:31                                   ` René Scharfe
2017-03-10 20:13                                 ` Junio C Hamano
2017-03-10 20:18                                   ` Jeff King
2017-03-10 22:04                                   ` René Scharfe
2017-03-10 23:33                                     ` Junio C Hamano
2017-03-11 14:17                                       ` René Scharfe
2017-03-10  0:14                           ` René Scharfe
2017-03-10  7:45                             ` Jeff King [this message]
2017-03-02 15:17     ` Ramsay Jones
2017-03-05 17:38       ` Lars Schneider
2017-03-05 22:16         ` Ramsay Jones

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=20170310074558.ifse3omthmtih73l@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=allan.x.xavier@oracle.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    --cc=larsxschneider@gmail.com \
    --cc=vegard.nossum@oracle.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).