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

["René Scharfe" <l.s.r@web.de>]

Am 10.03.2017 um 09:18 schrieb Jeff King:
> On Fri, Mar 10, 2017 at 01:14:16AM +0100, René Scharfe wrote:
>
>>>   2. Ones which just copy a single object, like:
>>>
>>>        memcpy(&dst, &src, sizeof(dst));
>>>
>>>      Perhaps we should be using struct assignment like:
>>>
>>>        dst = src;
>>>
>>>      here. It's safer and it should give the compiler more room to
>>>      optimize. The only downside is that if you have pointers, it is
>>>      easy to write "dst = src" when you meant "*dst = *src".
>>
>> Compilers can usually inline memcpy(3) calls, but assignments are
>> shorter and more pleasing to the eye, and we get a type check for
>> free.  How about this?
>
> Yeah, I mostly wasn't sure how people felt about "shorter and more
> pleasing". It _is_ shorter and there's less to get wrong. But the
> memcpy() screams "hey, I am making a copy" and is idiomatic to at least
> a certain generation of C programmers.
>
> I guess something like COPY(dst, src) removes the part that you can get
> wrong, while still screaming copy. It's not idiomatic either, but at
> least it stands out. I dunno.

Yes ...

> 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.

René