Re: [PATCH v1] Travis: also test on 32-bit Linux

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 List <git@vger.kernel.org>
Subject: Re: [PATCH v1] Travis: also test on 32-bit Linux
Date: Fri, 10 Mar 2017 12:57:19 -0500	[thread overview]
Message-ID: <20170310175719.cxol7d262n2rlcb2@sigill.intra.peff.net> (raw)
In-Reply-To: <04f4849c-e1e0-f0ac-5b1e-10a343391db4@web.de>

On Fri, Mar 10, 2017 at 05:20:13PM +0100, René Scharfe wrote:

> > 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 don't think the transformation could be wrong without the original
code being wrong.

I'm also not sure why mine would be unsafe and yours would be safe. It
seems like the other way around, because mine will do:

  *dst = ...

which would fail unless "dst" is a pointer. Whereas in yours, we end up
with:

  dst = ...

and somebody mistaking pointer assignment for a struct copy would not
notice.

But either way, I don't think we can have a rule like "you can use
struct assignment only if you don't have a pointer for the destination".
That's too arcane to expect developers and reviewers to follow. We
should either allow struct assignment or not.

Or have I totally misunderstood your point?

-Peff