)]}'
{
  "commit": "3a0799977bcb154d044828e96a25a01eb478de51",
  "tree": "6a00e8b5835136f647668ee3abf99b94dff1c711",
  "parents": [
    "e19ea55783bc3e1af5bc6a51775ed41b638aab10"
  ],
  "author": {
    "name": "Geoff Thorpe",
    "email": "geoff@openssl.org",
    "time": "Sat Sep 01 19:56:46 2001 +0000"
  },
  "committer": {
    "name": "Geoff Thorpe",
    "email": "geoff@openssl.org",
    "time": "Sat Sep 01 19:56:46 2001 +0000"
  },
  "message": "First step in fixing \"ex_data\" support. Warning: big commit log ...\n\nCurrently, this change merely addresses where ex_data indexes are stored\nand managed, and thus fixes the thread-safety issues that existed at that\nlevel. \"Class\" code (eg. RSA, DSA, etc) no longer store their own STACKS\nand per-class index counters - all such data is stored inside ex_data.c. So\nrather than passing both STACK+counter to index-management ex_data\nfunctions, a \u0027class_index\u0027 is instead passed to indicate the class (eg.\nCRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly\nand this is also thread-safe inside ex_data.c (though whether the caller\nmanages the return value in a thread-safe way is not addressed).\n\nThis does not change the \"get/set\" functions on individual \"ex_data\"\nstructures, and so thread-safety at that level isn\u0027t (yet) assured.\nLikewise, the method of getting and storing per-class indexes has not\nchanged, so locking may still be required at the \"caller\" end but is\nnonetheless thread-safe inside \"ex_data\"\u0027s internal implementation.\nTypically this occurs when code implements a new method of some kind and\nstores its own per-class index in a global variable without locking the\nsetting and usage of that variable. If the code in question is likely to be\nused in multiple threads, locking the setting and use of that index is\nstill up to the code in question. Possible fixes to this are being\nsketched, but definitely require more major changes to the API itself than\nthis change undertakes.\n\nThe underlying implementation in ex_data.c has also been modularised so\nthat alternative \"ex_data\" implementations (that control all access to\nstate) can be plugged in. Eg. a loaded module can have its implementation\nset to that of the application loaded it - the result being that\nthread-safety and consistency of \"ex_data\" classes and indexes can be\nmaintained in the same place rather than the loaded module using its own\ncopy of ex_data support code and state.\n\nDue to the centralisation of \"state\" with this change, cleanup of all\n\"ex_data\" state can now be performed properly. Previously all allocation of\nex_data state was guaranteed to leak - and MemCheck_off() had been used to\navoid it flagging up the memory debugging. A new function has been added to\nperfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The \"openssl\"\ncommand(s) have been changed to use this cleanup, as have the relevant test\nprograms. External application code may want to do so too - failure to\ncleanup will not induce more memory leaking than was the case before, but\nthe memory debugging is not tricked into hiding it any more so it may\n\"appear\" where it previously did not.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e10cea143eee11b96afca47d4bfaf7483c342af2",
      "old_mode": 33188,
      "old_path": "crypto/cpt_err.c",
      "new_id": "1b4a1cb4d40085ca7038b3725d4be45d3189a897",
      "new_mode": 33188,
      "new_path": "crypto/cpt_err.c"
    },
    {
      "type": "modify",
      "old_id": "be83f5617f5f076c671a3f362eb9d753d1e43076",
      "old_mode": 33188,
      "old_path": "crypto/cryptlib.c",
      "new_id": "6a2e546fba99300f02ed570b81750067cfd498fb",
      "new_mode": 33188,
      "new_path": "crypto/cryptlib.c"
    },
    {
      "type": "modify",
      "old_id": "53b85238c092d79ff644189370c9fea89d667a02",
      "old_mode": 33188,
      "old_path": "crypto/crypto.h",
      "new_id": "b708a07dd47491cc66a742b027320a7373dd3fdc",
      "new_mode": 33188,
      "new_path": "crypto/crypto.h"
    },
    {
      "type": "modify",
      "old_id": "ff32ad5be6b35ed724b4ada6bff2c9e8b555d883",
      "old_mode": 33188,
      "old_path": "crypto/ex_data.c",
      "new_id": "af8ee704d740e16c4cee16f47fce7eecb623b847",
      "new_mode": 33188,
      "new_path": "crypto/ex_data.c"
    }
  ]
}