)]}'
{
  "commit": "fc73d06fed76dd7cde37d3704949d01391ea0032",
  "tree": "559c42a15e35bbaf0a4e15c5d9557967930ba23a",
  "parents": [
    "a815be4b5de7f7df2da664049fdb04874d37016a"
  ],
  "author": {
    "name": "Laslo Hunhold",
    "email": "dev@frign.de",
    "time": "Mon Oct 03 23:13:26 2022 +0200"
  },
  "committer": {
    "name": "Laslo Hunhold",
    "email": "dev@frign.de",
    "time": "Mon Oct 03 23:13:26 2022 +0200"
  },
  "message": "Convert GRAPHEME_STATE to uint_least16_t and remove it\n\nI was never quite happy with the fact that the internal state-struct\nwas visible in the grapheme.h-header, given the declaration of the\nfields only namely served internal purposes and were useless noise to\nthe reader.\n\nTo keep it in was merely a choice made because I had always hoped\nto be able to implement maybe a few more state-based pairwise\nsegmentation check functions and use the GRAPHEME_STATE type in more\nplaces, but now after implementing the algorithms it becomes clear that\nthey all do not satisfy these pairwise semantics.\n\nThe first logical step was to convert the struct to an uint_least16_t,\nwhich provides enough space (at least 16 bits) to store all the complete\nstate, and have internal deserialiation and serialization functions.\n\nThe remaining question was if the\n\n\ttypedef uint_least16_t GRAPHEME_STATE\n\nshould be removed. I took inspiration from the Linux kernel coding\nstyle[0], which in section 5b lays out the exact case of typedeffing\nan integer that is meant to store flags (just like in our case).\nIt is argued there that there needs to be a good reason to typedef an\ninteger (e.g. given it might change by architecture or maybe change in\nlater versions). Both cases are not given here (we will _never_ need\nmore than 16 bits to store the grapheme cluster break state and you can\neven reduce more wastage, e.g. for storing the prop which never exceeds\n4 bits given NUM_CHAR_BREAK_PROPS \u003d\u003d 14 \u003c 15 \u003d\u003d 2^4-1), and I must admit\nthat it improves readability a bit given you finally know what you\u0027re\ndealing with.\n\nThe expression\n\n\tGRAPHEME_STATE state \u003d 0;\n\nadmittedly looks a little fishy, given you don\u0027t really know what happens\nbehind the scenes unless you look in the header, and I want all of the\nsemantics to be crystal clear to the end-user.\n\n[0]:https://www.kernel.org/doc/html/latest/process/coding-style.html#typedefs\n\nSigned-off-by: Laslo Hunhold \u003cdev@frign.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "8d7eb403a53cc874cc5da1293775c2fad789374d",
      "old_mode": 33188,
      "old_path": "benchmark/character.c",
      "new_id": "854645d0e9444cdc740be0dfe8d4d9ab2d2620a8",
      "new_mode": 33188,
      "new_path": "benchmark/character.c"
    },
    {
      "type": "modify",
      "old_id": "cf7b68d7d4fbba8b73fc35955599a009610777a9",
      "old_mode": 33188,
      "old_path": "grapheme.h",
      "new_id": "4df655106a4a99385adc911e450e3360eba024d0",
      "new_mode": 33188,
      "new_path": "grapheme.h"
    },
    {
      "type": "modify",
      "old_id": "995fd7a521cad9b83853abb1f5c71ca4a8bad61d",
      "old_mode": 33188,
      "old_path": "man/grapheme_is_character_break.sh",
      "new_id": "3c0fe541a87c32d6369783fce02b390a0601dd8a",
      "new_mode": 33188,
      "new_path": "man/grapheme_is_character_break.sh"
    },
    {
      "type": "modify",
      "old_id": "4d34b98f0a9dd1e3030dbc7aa41b75279f04d015",
      "old_mode": 33188,
      "old_path": "src/character.c",
      "new_id": "4240332cf93b0f4a14bd210f3b0a66d3e185e71a",
      "new_mode": 33188,
      "new_path": "src/character.c"
    }
  ]
}