грустный хак

[netch80]

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

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

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

Comments

[leschinsky oleg (from livejournal.com)]

Первые признаки превращения в вендора? (Если вы понимаете о чем я) %)

[tzirechnoy.livejournal.com]

Любопытно: а что за имбеддед Вы разрабатываете?

[netch]

Realtime monitoring. Единообразные шаблоны данных, но секундные реакции (в отличие от минутных, как для типичных сейчас систем).

[rusoexpato.livejournal.com]

Интересно, при ошибке снятия и отсутствии источника, значение счётчика тоже имеет смысл?

[netch]

В нём что-то должно передаваться.

[starcat13.livejournal.com]

считаем счетчик signed, отрицательные значения - коды..

[knyar.livejournal.com]

То, что параметры не так быстро растут, чтобы переполнить 64 бита, совсем не значит, что они гарантированно влезут в 32. Да и терять половину области значений только лишь для того, чтобы закодировать несколько сообщений об ошибке — сомнительное решение, по-моему.

[starcat13.livejournal.com]

Половина области значений - это именно 63 бита, а не 32.

[knyar.livejournal.com]

Прошу прощения, не проснулся ещё :)
Чем тогда ваше предложение принципиально отличается от предложенного изначально?

[netch]

Насколько я понимаю, это то же самое, но переименованное.

[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. Пора валить из ЖЖ.