Метод ostringstream :: write изменяет входной параметр

Рассмотрим следующий фрагмент, который получает некоторые двоичные данные и записывает их в ostringstream объект:

unsigned char* payload;
unsigned long  size;

GetData(&payload, &size);

std::cout << md5(payload, size) << std::endl;

std::ostringstream stream;
stream.write((const char*)payload, size);

std::cout << md5(payload, size) << std::endl;

Проблема состоит в том, что два напечатанных значения хеша отличаются друг от друга, что означает payload был изменен. Я пытался открыть stream в двоичном режиме с помощью std::ostringstream stream(std::ios::out | std::ios::binary), это не имело значения, я не ожидал, что так или иначе.

Еще один факт: я получаю другую контрольную сумму из второго оператора печати каждый раз, когда перезапускаю программу. Первый хеш всегда один и тот же.

Теперь, как мне правильно записать мои двоичные данные в ostringstream? Может ли проблема быть брошена на const char* (GetData метод принимает unsigned char** как первый параметр)?

ОБНОВЛЕНИЕ: В свете комментариев, вот еще несколько объяснений:

  • Сравнивая двоичные различия исходных данных и записанных данных, я увидел, что записанные данные в некоторых местах сместились вправо (на 24 байта). Он также имеет несколько добавленных байтов в самом начале. Я все еще думаю, что это как-то связано с актерами.
  • Там нет больше кода между GetData и фактическое письмо.
  • GetData работает правильно, так как контрольная сумма после вызова правильная (я знаю, какой должна быть контрольная сумма).
  • Я не могу опубликовать компилируемый код, потому что GetData, И это не обязательно, я выделил проблему на линию, где write называется.
  • Сведения о системе: gcc версия 4.6.3 в Ubuntu 12.04 64bit

0

Решение

Загадка проблемы оказывается в размере данных.

После экспериментов с различными значениями размера, было обнаружено, что ostringstreamВнутренний буфер составляет около 65 КБ, если быть точным, 65504 байта. Когда размер больше, происходят странные сдвиги и искалеченные байты.

Обходной путь должен использовать:

stream.rdbuf()->pubsetbuf((const char*)payload, payloadSize)

вместо write метод. Но когда эта область заканчивается, полезная нагрузка будет признана недействительной и stream больше не может использоваться где-либо еще. В моем случае это нужно было использовать где-то еще.

Это показало, что:

  • Я был действительно прав, что проблема с ostringstream но не с хешем или чем-то еще.
  • Строковые потоки STL, очевидно, имеют ограничение размера буфера по умолчанию. Это следует помнить в будущем.
0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]