From: René Scharfe <l.s.r@web.de>
Date: Fri, 10 Mar 2017 22:04:32 GMT
Subject: Re: [PATCH v1] Travis: also test on 32-bit Linux
Message-ID: <c93a61a4-05d9-8e49-9734-12c81289517b@web.de>
In-Reply-To: <xmqqfuikyjoo.fsf@gitster.mtv.corp.google.com>

Am 10.03.2017 um 21:13 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
>
>>> I think this misses the other two cases: (*dst, src) and (*dst, *src).
>>
>> ... and that's why I left them out.  You can't get dst vs. *dst wrong
>> with structs (at least not without the compiler complaining); only
>> safe transformations are included in this round.
>
> I haven't followed this discussion to the end, but the omission of 2
> out of obvious 4 did pique my curiosity when I saw it, too, and made
> me wonder if the omission was deliberate.  If so, it would be nice
> to state why in the log message (or in copy.cocci file itself as a
> comment).
>
> It also made me wonder if we would be helped with a further
> combinatorial explosion from "T **dstp, **srcp" and somesuch (in
> other words, I am wondering why a rule for 'T *src' that uses '*src'
> need to be spelled out separately when there already is a good rule
> for 'T src' that uses 'src'---is that an inherent restriction of the
> tool?).

There are redundancies. This semantic patch here:

	@@
	type T;
	T dst;
	T *src;
	@@
	- memcpy(&dst, src, sizeof(dst));
	+ dst = *src;

would match e.g. this (from convert.c):

	memcpy(&new_stats, &stats, sizeof(new_stats));

and transform it to:

	new_stats = *&stats;

We'd need just one more rule to remove the "*&" part and could then get 
rid of two of the "T src" variants, to arrive at something like this:

	@@
	type T;
	T dst, src;
	@@
	- memcpy(&dst, &src, sizeof(src));
	+ dst = src;

	@ r @
	type T;
	T dst;
	T *src;
	@@
	(
	- memcpy(&dst, src, sizeof(dst));
	+ dst = *src;
	|
	- memcpy(&dst, src, sizeof(*src));
	+ dst = *src;
	|
	- memcpy(&dst, src, sizeof(T));
	+ dst = *src;
	)

	@ depends on r @
	expression E;
	@@
	- *&
	  E

René