грустный хак

[netch80]

Обнаружили, что там, где мы раньше просто передавали счётчик в 8 байтах, надо передавать ещё два значения — типа "ошибка снятия" и "отсутствие источника". Расширять некуда — грубо говоря, это embedded, протоколы и форматы в общем установлены. Но параметры не так быстро растут, чтобы переполнить 64 бита.

Так что выдвинул на внутреннее обсуждение предложение: "на ходу" сократить его до 63 бит, а случай старшего бита равного 1 применить на спец-значения. Вот жду до понедельника, будут ли фатальные возражения...

Чувствую себя сотрудником Microsoft — согласно уровню извращений — заказчикам тоже придётся перестраиваться (хоть и не срочно).

Comments

[gegmopo4.livejournal.com]

UTF-64

[netch]

В каком смысле?

[gegmopo4.livejournal.com]

UTF-8 и UTF-16 — это решения такой же внезапно возникшей проблемы.

Если серьёзно, то имеет смысл заложить возможность расширения, мало ли какие и сколько ещё параметров понадобиться. Часть из тех 6 критериев, которыми руководствовались авторы UTF-8, может быть актуальна. А значит:
1. Кроме старшего единичного бита, в сексагинтаквартетах зарезервировать ещё по крайней мере один для обозначения начала последовательности. Это нужно для безопасной синхронизации.
2. По крайней мере в первом элементе несколько бит зарезервировать для кодирования длины последовательности. По крайней мере одно из этих значений длины должно быть зарезервировано на случай, если этих бит для длины не хватит (и длина будет кодироваться по-другому).
3. Декодировщик должен просто пропускать элементы с неизвестными префиксами (отмечая, что случилось что-то странное).
4. Может быть по реализации выгоднее использовать для спецзначений префиксы фиксированной длины — старшие 8, 16 или даже 32 бита.

Самый важный здесь 3-й пункт. Если декодер встретил 0*, то это просто старый добрый счётчик, если 10000000* — то это одно из двух (или сколько вы там введёте завтра) спецзначений. А если иначе — значит послезавтра уже наступило.

P. S. Пора валить из ЖЖ.