git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
René Scharfe <l.s.r@web.de>
Date
Mar 10, 2017, 18:31 UTC
Message-ID
<3a1cd5cf-cf13-7ef1-7b47-d4b083b64d11@web.de>
In-Reply-To
<20170310175719.cxol7d262n2rlcb2@sigill.intra.peff.net>
Am 10.03.2017 um 18:57 schrieb Jeff King:
Show 10 quoted lines
> 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.

Avoiding to introduce bugs with automatic transformations is essential, indeed -- if we're not careful here we'd be better off keeping the original code.

Show 12 quoted lines
> 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.

If dst is a struct then having *dst on the left-hand side results in a compiler error -- you can't get that one wrong. If it's a pointer then both dst and *dst can be valid (pointer assignment vs. content copy), so there is the possibility of making a mistake without the compiler noticing.

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

With an automatic transformation in place it's more like "you can't use memcpy() in this case any more as it gets turned into an assignment with the next cocci patch". I think we shouldn't be that restrictive for pointers as destinations (yet?).

René
Previous: Jeff KingNext: Junio C Hamano
Message 28 of 36 in “Travis: also test on 32-bit Linux”
  1. Travis: also test on 32-bit LinuxJohannes Schindelin, Feb 28, 2017
  2. Johannes SchindelinFeb 28, 2017
  3. Junio C HamanoMar 2, 2017
  4. Travis: also test on 32-bit LinuxLars Schneider, Mar 2, 2017
  5. Johannes SchindelinMar 2, 2017
  6. Lars SchneiderMar 2, 2017
  7. Johannes SchindelinMar 2, 2017
  8. Christian CouderMar 2, 2017
  9. Junio C HamanoMar 2, 2017
  10. Johannes SchindelinMar 3, 2017
  11. Junio C HamanoMar 3, 2017
  12. Junio C HamanoMar 4, 2017
  13. Junio C HamanoMar 4, 2017
  14. Lars SchneiderMar 4, 2017
  15. Vegard NossumMar 4, 2017
  16. Vegard NossumMar 4, 2017
  17. Vegard NossumMar 4, 2017
  18. Jeff KingMar 5, 2017
  19. line-log: use COPY_ARRAY to fix mis-sized memcpyJeff King, Mar 5, 2017
  20. Vegard NossumMar 5, 2017
  21. Jeff KingMar 5, 2017
  22. René ScharfeMar 10, 2017
  23. Jeff KingMar 10, 2017
  24. René ScharfeMar 10, 2017
  25. Jeff KingMar 10, 2017
  26. René ScharfeMar 10, 2017
  27. Jeff KingMar 10, 2017
  28. René ScharfeMar 10, 2017
  29. Junio C HamanoMar 10, 2017
  30. Jeff KingMar 10, 2017
  31. René ScharfeMar 10, 2017
  32. Junio C HamanoMar 10, 2017
  33. René ScharfeMar 11, 2017
  34. Ramsay JonesMar 2, 2017
  35. Lars SchneiderMar 5, 2017
  36. Ramsay JonesMar 5, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.