Mmap с прямым порядком байтов - PullRequest
Новая
       29

Mmap с прямым порядком байтов

2 голосов
/ 22 июня 2009

Если я буду использовать mmap для написания uint32_t, возникнут ли у меня проблемы с соглашениями с прямым или прямым порядком байтов? В частности, если я напишу некоторые данные mmap 'ed на машине с прямым порядком байтов, возникнут ли у меня проблемы при попытке прочитать эти данные на машине с прямым порядком байтов?

Ответы [ 2 ]

5 голосов
/ 22 июня 2009

Если вы используете mmap, вы, вероятно, обеспокоены скоростью и эффективностью. У вас есть несколько вариантов.

  1. Оберните все ваши чтения и записи с помощью функций htonl, htons, ntohl, ntohs. Вызов порядка htonl (хост-сеть) в Windows преобразует данные с прямым порядком байтов в старший. На других архитектурах это будет просто. Эти преобразования имеют накладные расходы, но в зависимости от ваших операций они могут быть или не быть значительными. AFAIK, это подход, используемый SQLite
  2. Другой вариант - всегда записывать данные в формате хоста и предоставлять процедуры, если пользователям нужно переносить свои данные между платформами. Базы данных обычно считывают и записывают данные в формате хоста, но предоставляют такие инструменты, как bcp, которые будут записывать в ASCII или сетевой порядок байтов.
  3. Вы можете пометить заголовок вашего файла меткой порядка байтов. Когда ваша программа запускается, она сравнивает порядок байтов с порядком в файле и, при необходимости, предоставляет любой перевод. Это часто хорошо для простых форматов данных, таких как UTF-16, но не для форматов, где у вас есть несколько типов переменной длины.

Кроме того, если вы делаете такие вещи, как предоставление префиксов длины или смещение файлов, у вас может быть сочетание 32-битных и 64-битных указателей. 32-разрядная платформа не может создать представление mmap размером более 4 ГБ, поэтому маловероятно, что вы будете поддерживать файлы размером более 4 ГБ. Такие программы, как rrdtool, используют этот подход и поддерживают гораздо большие размеры файлов на 64-битных платформах. Это означает, что ваш двоичный файл не будет совместим на разных платформах, если вы используете размер указателя платформы внутри вашего файла.

Моя рекомендация заключается в том, чтобы заранее игнорировать все проблемы с порядком байтов и спроектировать систему для быстрой работы на вашей платформе. Если / когда вам нужно переместить ваши данные на другую платформу, тогда выберите самый простой / быстрый / наиболее подходящий способ сделать это. Если вы начнете с попытки создания независимого от платформы формата данных, вы, как правило, будете делать ошибки, и вам придется вернуться и исправить их позже. Это особенно проблематично, когда 99% данных находятся в правильном порядке байтов, а 1% - неверно. Это означает, что исправление ошибок в вашем коде перевода данных приведет к поломке существующих клиентов на всех платформах.

Перед написанием кода для поддержки более чем одной платформы вам нужно будет установить многоплатформенный тест.

2 голосов
/ 22 июня 2009

Да.

mmap отображает необработанные данные файла в адресное пространство процесса. Он ничего не знает о том, что представляют необработанные данные, не говоря уже о том, чтобы попытаться преобразовать их для вас. Если вы отображаете один и тот же файл на архитектурах с различным порядком байтов, вам придется выполнить любое необходимое преобразование самостоятельно.

В качестве переносимого формата данных на компьютерах я бы рассмотрел что-то с более высоким уровнем абстракции, такое как JSON или даже XML, которое не привязывает формат данных к конкретной реализации. Но это действительно зависит от ваших конкретных требований.

...