)]}'
{
  "commit": "c4d7bfb9895efc196b04f18f5da77fd99b39212a",
  "tree": "57db3ae060b7256de20cd60f887e1a18a42fc550",
  "parents": [
    "8aab4c94f039132b270ab03968f74d24d315e141"
  ],
  "author": {
    "name": "Ian Lance Taylor",
    "email": "iant@golang.org",
    "time": "Mon Jun 30 21:26:11 2025 -0700"
  },
  "committer": {
    "name": "Ian Lance Taylor",
    "email": "iant@golang.org",
    "time": "Tue Jul 08 15:47:48 2025 -0700"
  },
  "message": "runtime: avoid libc memmove and memclr\n\nThe libc memmove and memclr don\u0027t reliably operate on full memory words.\nWe already avoided them on PPC64, but the same problem can occur even\non x86, where some processors use \"rep movsb\" and \"rep stosb\".\nAlways use C code that stores full memory words.\n\nWhile we\u0027re here, clean up the C code. We don\u0027t need special handling\nif the memmove/memclr pointers are not pointer-aligned.\n\nUnfortunately, this will likely be slower. Perhaps some day we can\nhave our own assembly code that operates a word at a time,\nor we can use different operations when we know there are no pointers.\n\nChange-Id: I87f66331cc04aa07cb28f59cbc16810dc903c049\nReviewed-on: https://go-review.googlesource.com/c/gofrontend/+/685178\nReviewed-by: Dmitri Shuralyov \u003cdmitshur@google.com\u003e\nReviewed-by: Than McIntosh \u003cthanm@golang.org\u003e\nReviewed-by: Cherry Mui \u003ccherryyz@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "53b8117853923a32fc364b68d59cd911ef2ada18",
      "old_mode": 33188,
      "old_path": "libgo/runtime/go-memclr.c",
      "new_id": "84df98db6d41a6b42912e11a8c69df1d3185d92e",
      "new_mode": 33188,
      "new_path": "libgo/runtime/go-memclr.c"
    },
    {
      "type": "modify",
      "old_id": "1ca3f4822b736fadbe0db35a5784f730b0f5f5b2",
      "old_mode": 33188,
      "old_path": "libgo/runtime/go-memmove.c",
      "new_id": "1dbd2b39273471256764d61d4af747e1d6e7c90e",
      "new_mode": 33188,
      "new_path": "libgo/runtime/go-memmove.c"
    }
  ]
}