NNCP баги и оптимизации

http://lists.cypherpunks.ru/archive/nncp-devel/2107/0249.html
Один человек использует NNCP с Raspberry Pi и у него получилось
воспроизвести проблему с обрезанными пакетами и другой чертовщиной.
Выяснилось что 32-х битная система делает некорректные пакеты. Везде
старался делать int64 где может быть большой размер (например файла,
а не внутреннего буфера), но в самом важном месте, во время создания
шифрованного пакета -- был простой int, из-за которого могли получаться
или отрицательные значения размера или просто меньшие по размеру.
Поставил себе 32-х битную FreeBSD -- с новой версией всё исправилось.

Вообще я частенько про себя думаю что "ну кто ж будет то запускать и
использовать 32-бит софт на ПК"? Но RPi штука хорошо подходящая для NNCP
и распространённая в природе -- всё же не хочется забивать на подобную
платформу.

Ещё я начал было писать функциональные тесты на sharness, но забуксовал
на том, что конфиг в NNCP это Hjson, который хоть и может быть легко
преобразован в JSON, но как с ним работать то добавляя/удаляя/меняя
поля? jq (а точнее я сейчас использую gojq, jq удалил напрочь) позволит
прочитать поля, но не изменить что-то в дебрях внутри. Недавно узнал про
jo и gjo утилиты (40cb8a257f73cc02ea67ad7d50d6a5064ccda81b) и как раз к
месту пригодились и на них начал писать вот такие портянки:

    [...]
    idB=$(gojq .self.id $spoolB/cfg.json)
    exchpubB=$(gojq .self.exchpub $spoolB/cfg.json)
    signpubB=$(gojq .self.signpub $spoolB/cfg.json)

    cfgA=$(gjo \
        spool=$spoolA log=$spoolA/log \
        self=$(gjo id=$idA \
            exchpub=$exchpubA exchprv=$exchprvA \
            signpub=$signpubA signprv=$signprvA \
        ) \
        neigh=$(gjo \
            self=$(gjo id=$idA \
                exchpub=$exchpubA exchprv=$exchprvA \
                signpub=$signpubA signprv=$signprvA \
            ) \
            nodeB=$(gjo id=$idB \
                exchpub=$exchpubB exchprv=$exchprvB \
                signpub=$signpubB signprv=$signprvB \
            )
        )
    )

Вроде бы ужасно, но в принципе даже читаемо глазами вполне. Но до самого
теста дело всё равно так и не дошло, психанул, и добавил возможность
преобразовывать конфиг в директорию, полностью по аналогии что видел в
mlmmj (aac872add6b3defe52aef4d70dbb54a6fcddf973) где всё в виде простых
текстовых файлов, флаговых файлов и поддиректорий.
http://www.nncpgo.org/Configuration-directory.html
Это в тестах очень легко будет модифицировать. NNCP внутри себя может
сконвертировать эту директорию в JSON (точнее структуру аналогичную
после декодирования JSON), так же как и Hjson сначала конвертируется в
JSON. Ну и в принципе автоматизации это стало поддаваться, ибо мысль не
покидает о явном неудобстве списка подписантов multicast area
(ed3fd3765f912c43a16adf4f7032b851a447c695).

Плюс окончательно прооптимизировал реализацию MTH
(26d0fad8f0c8e523ec77c70dec244afc2c0e86e3). Старая осталась
исключительно как reference (можно вызвать через nncp-hash -force-fat).
А новая реализация значительно сократилась по коду, что меня удивило, и
потребляет только самый необходимый минимум памяти: как только
появляются элементы которые можно "схлопнуть" -- сразу хэшируются и
создают элемент более высокого уровня. И это применяется и к докачке тоже.
Думал что будет значительно всё сложнее, но нет.