Добрый день,

Понадобилось реализовать блочное шифрование. Чтобы не заботиться о том, поступают ли данные из строки или файла, решил передавать в функцию шифрования потоки istream, ostream. Столкнулся с тем, что в конце расшифрованной строки образуется какой-то мусор. Чтобы проверить себя, создал отдельный проект, который только пишет и читает текст в/из stringstream и обнаружил ту же проблему.

C++ (Qt)
#include <iostream>
#include <sstream>
 
#include <cstring>
 
using namespace std;
 
int main(int argc, char *argv[])
{
	/* Исходная строка */
	stringstream ss_in("Hello, World!");
	clog << "ss_in.str().length() = "
		<< ss_in.str().length()
		<< endl;
 
	stringstream ss_intermediate;
	char buf[8];
	size_t bytes_written_into_ss_intermediate = 0;
	while (ss_in.good()) {
		/* Читаем данные в буфер. т.к. шифрование 
		 * работает с блоками по 64-бита */
		memset(buf, 0, 8);
		ss_in.read(buf, 8);
		/* Здесь могла бы быть процедура шифрования... */
		ss_intermediate.write(buf, 8);
		bytes_written_into_ss_intermediate += 8;
	}
	clog << bytes_written_into_ss_intermediate
		<< " bytes written into ss_intermediate"
		<< endl;
 
	clog << "ss_intermediate.str().length() = "
		<< ss_intermediate.str().length()
		<< endl
		<< "'" << ss_intermediate.str() << "'"
		<< endl;
 
	stringstream ss_out;
	size_t bytes_written_into_ss_out = 0;
	/* А здесь по неясной мне причине в потоке 
	 * оказывается 24 байта доступных для чтения,
	 * 16 из которых были в него записаны,
	 * а еще 8 NULL-байтов появились каким-то
	 * непостижимым образом. Может это проделки 
	 * запасливого распределителя памяти, заранее
	 * хапнувшего себе еще 8 байт capacity под 
	 * будущие нужды, но с какой радости он 
	 * пихает их в поток как данные? */
	while (ss_intermediate.good()) {
		memset(buf, 0, 8);
		ss_intermediate.read(buf, 8);
		ss_out.write(buf, 8);
		bytes_written_into_ss_out += 8;
	}
	clog << bytes_written_into_ss_out
		<< " bytes written into ss_out"
		<< endl;
 
	clog << "ss_out.str().length() = "
		<< ss_out.str().length()
		<< endl
		<< "'" << ss_out.str() << "'"
		<< endl;
 
	getc(stdin);
}
 
 

Вывод:

Непонятно, откуда берутся лишние 8 байт?

Здесь говорится о том, что если символов в потоке меньше, чем запрошенное n, то в массив, на который указывает s, запишутся только те байты, что есть в потоке, а для самого объекта istream будут установлены флаги eofbit и failbit. Меня же интересует природа нулевых байтов, которые появляются в хвосте потока, словно были туда записаны.

Ох, во всем хочется видеть интуитивно понятные вещи. Но иногда все же приходится отбросить все предположения и рыться в документации до последней запятой.
Меня возмущает тот факт, что условие in.good() не останавливает меня до того, как я попытаюсь прочитать "пустой" поток. Как оказалось, в действительности дело обстоит так:

1. Я пишу в поток N байтов;
2. Я читаю из потока ровно N байтов;
3. Однако, чтобы isream понял, что байты закончились, его нужно пнуть еще на 1 байт вперед. чтобы он наткнулся на EOF. И только после пинка он установит eofbit.

И методу good() на полном серьезе следовало бы называться testBitGood() в соответствии с его назначением, а вовсе не размытым "все_хорошо"  
Таким образом условием while нужно либо заглядывать (peek) в следующий байт, чтобы он не был EOF, либо смотреть число реально прочитанных байтов, вызывая gcount() и выходить из цикла если прочитано 0.

Вот и пример такого интуитивно непонятного, но рабочего чтения из потока

C++ (Qt)
void testWriteAndReadStringstream( ) {
    const size_t BufferSize = 8;
 
    char buf[BufferSize];
    string str("Hello, World!");
    strncpy_s(buf, BufferSize-1, str.data(), BufferSize);
    stringstream ss;
    ss.write(buf, BufferSize);
 
    while (EOF != ss.peek()) {
        ss.read(buf, BufferSize);
        clog << ss.gcount() << " bytes read" << endl;
    }
}
 

Тогда мы рискуем "потерять" последние байты, которые не образуют целый блок


Например, мы читаем строку исходного текста перед шифрованием, длина которой может и не быть кратной размеру блока. Тогда в "хвосте" окажется несколько байт, пусть 2, а read мы просим постоянно читать 8. И в один прекрасный (последний) момент read читая следующие 8 байт прочитает 2 и натолкнется на EOF, после чего установит eofbit и failbit, но байты из "хвоста" все равно будут прочитаны.

Насколько помню, так всегда и было (не очень удобно как и многое в std). Обычно проверяют good() сразу после read(). При форматированном I/O этой проблемы нет, можно просто while (!ss.eof()).

А что это за байты такие? Просто и хорошо испускать exception если хоть что-то "не гуд", т.е. приложение не должно нарываться на конец файла. Для чтения данных переменной длины нужно предвычислить их число/размер используя длину файла/тега. А просто "прочитать все что есть в файле" может загнать приложение "куда Макар телят не гонял"