История изменений

Однажды реализовывал библиотеку для работы с бинарным форматом. У формата было две версии, с первой было всё в порядке, описание было паршивое, порядок байт указан не был, но я предположил, что это big-endian, ибо извлечённые данные бились (сходились с ожидаемыми), реализовал, и всё нормально работало. Второй формат расширял первый, убирая часть полей и добавляя много новых, большинство из которых в обоих форматах либо short, либо строки. Но одно поле не билось. Одно единственное.

Почесал репу, поменял порядок байт на little-endian, поле стало биться. Хм. Подумав хорошенько, я понял, что с первым форматом мог вполне ошибиться, ведь, ни с short, ни со строками в однобайтовой кодировке из-за порядка байт никаких проблем быть не может. Ну, ОК. Доделал, начал тестить, первый формат таки сломался (часть кода была общая), нашлись интовые (int32) поля. Вернул в зад, поставил, выставил разный порядок для двух форматов. Протестировал второй, оказалось, что всё равно не бьются общие поля с первым форматом. В этот момент я уже не понимал, что происходит и вычитывал код, выискивая, где же я натупил. Целый день ломал над этим голову, проверяя самые бредовые предположения.

В итоге оказалось, что я нигде не натупил, а разработчики формата — дебилы. Старые поля формировал старый код, новые поля формировал новый, и у них был разный порядок байт. В документации это отразить, конечно же, не удосужились.

Однажды реализовывал библиотеку для работы с бинарным форматом. У формата было две версии, с первой было всё в порядке, описание было паршивое, порядок байт указан не был, но я предположил, что это big-endian, ибо извлечённые данные бились (сходились с ожидаемыми), реализовал, и всё нормально работало. Второй формат расширял первый, убирая часть полей и добавляя много новых, большинство из которых либо short, либо строки. Но одно поле не билось. Одно единственное.

Почесал репу, поменял порядок байт на little-endian, поле стало биться. Хм. Подумав хорошенько, я понял, что с первым форматом мог вполне ошибиться, ведь, ни с short, ни со строками в однобайтовой кодировке из-за порядка байт никаких проблем быть не может. Ну, ОК. Доделал, начал тестить, первый формат таки сломался (часть кода была общая), нашлись интовые (int32) поля. Вернул в зад, поставил, выставил разный порядок для двух форматов. Протестировал второй, оказалось, что всё равно не бьются общие поля с первым форматом. В этот момент я уже не понимал, что происходит и вычитывал код, выискивая, где же я натупил. Целый день ломал над этим голову, проверяя самые бредовые предположения.

В итоге оказалось, что я нигде не натупил, а разработчики формата — дебилы. Старые поля формировал старый код, новые поля формировал новый, и у них был разный порядок байт. В документации это отразить, конечно же, не удосужились.

Однажды реализовывал библиотеку для работы с бинарным форматом. У формата было две версии, с первой было всё в порядке, описание было паршивое, порядок байт указан не был, но я предположил, что это big-endian, ибо данные бились, реализовал, и всё нормально работало. Второй формат расширял первый, убирая часть полей и добавляя много новых, большинство из которых либо short, либо строки. Но одно поле не билось. Одно единственное.

Почесал репу, поменял порядок байт на little-endian, поле стало биться. Хм. Подумав хорошенько, я понял, что с первым форматом мог вполне ошибиться, ведь, ни с short, ни со строками в однобайтовой кодировке из-за порядка байт никаких проблем быть не может. Ну, ОК. Доделал, начал тестить, первый формат таки сломался (часть кода была общая), нашлись интовые (int32) поля. Вернул в зад, поставил, выставил разный порядок для двух форматов. Протестировал второй, оказалось, что всё равно не бьются общие поля с первым форматом. В этот момент я уже не понимал, что происходит и вычитывал код, выискивая, где же я натупил. Целый день ломал над этим голову, проверяя самые бредовые предположения.

В итоге оказалось, что я нигде не натупил, а разработчики формата — дебилы. Старые поля формировал старый код, новые поля формировал новый, и у них был разный порядок байт. В документации это отразить, конечно же, не удосужились.

Однажды реализовывал библиотеку для работы с бинарным форматом. У формата было две версии, с первой было всё в порядке, описание было паршивое, порядок байт указан не был, но я предположил, что это big-endian, ибо данные бились, реализовал и всё нормально работало. Второй формат расширял первый, убирая часть полей и добавляя много новых, большинство из которых либо short, либо строки. Но одно поле не билось. Одно единственное.

Почесал репу, поменял порядок байт little-endian, поле стало биться. Хм. Подумав хорошенько, я понял, что с первым форматом мог вполне ошибиться, ведь, ни с short, ни со строками в однобайтовой кодировке из-за порядка байт никаких проблем быть не может. Ну, ОК. Доделал, начал тестить, первый формат таки сломался (часть кода была общая), нашлись интовые (int32) поля. Вернул в зад, поставил, выставил разный порядок для двух форматов. Протестировал второй, оказалось, что всё равно не бьются общие поля с первым форматом. В этот момент я уже не понимал, что происходит и вычитывал код, выискивая, где же я натупил. Целый день ломал над этим голову, проверяя самые бредовые предположения.

В итоге оказалось, что я нигде не натупил, а разработчики формата — дебилы. Старые поля формировал старый код, новые поля формировал новый, и у них был разный порядок байт. В документации это отразить, конечно же, не удосужились.