Глючит fwrite (пишет 5 байт вместо 4)

26.03.2011, 11:49. **Показов** 2406. **Ответов** 4

Среда: C++ Builder 2010.

В некий файл пишутся всякие бинарные данные (типы char/int/long) при помощи fwrite. Казалось бы, задача проще некуда. Много раз выполяется команда:

fwrite(&x, 4, 1, f);

x — типа unsigned long, в ней в момент глюка содержится значение 0xC000000A. Казалось бы, в файле должны оказаться байты: 0x0A 0x00 0x00 0xC0. Но в реальности перед ними откуда-то берётся пятый байт, 0x0D (т. е. 13 — мистика, блин!)

До и после этого fwrite стоят fflush(f), так что проблема чётко в данной строке. При этом все остальные данные (в том числе тот же самый 0xC000000A) и до и после глючащей позиции с помощью той же самой команды записываются нормально.

Единственное, на что тут могу грешить — где-то раньше до этого была произведена запись в недопустимую область памяти. Но всё равно проявление этого весьма странное. Может, дело в чём-то другом? Бьюсь третий день.

Добавлено через 14 часов 31 минуту

Переделал вывод под ofstream — работает как часы. Крайне странная история.

Вообще, какой способ работы с файлами предпочтительнее в Windows? Ибо выбор большой.

Evg · 26.03.2011, 12:39

Сообщение от alextram

Но в реальности перед ними откуда-то берётся пятый байт, 0x0D (т. е. 13 — мистика, блин!)

А ты уверен, что ты в этот файл больше нигде ничего не записывал? Потому что мистики на свете не бывает, а мистика в программировании в 999999 случаях из 1000000 является причиной ошибочно написанного исходника. Ради интереса сделай два одинаковых вызова fwrite подряд. Если окажется, что после этого размер файла равен 10 байтам, то то реально мистика, если 9, то значит где-то в программе есть ещё одно место, которое этот несчастный перевод строки вклеивает

@odip · 26.03.2011, 16:50

Замена кода 0x0A на два кода - 0x0D 0x0A происходит в текстовом режиме работы с файлом
Поэтому косяк где-то есть, но у тебя

А вообще приводи минимальную рабочую программу, которая демонстрирует глюк

Evg · 26.03.2011, 17:00

Сообщение от odip

Замена кода 0x0A на два кода - 0x0D 0x0A происходит в текстовом режиме работы с файлом

Вот чёрт

Совсем забыл про такую особенность винды. На коротком примере оно действительно проявляется

C

1
2
3

FILE *fp = fopen ("a.txt", "w");
int x = 0x0a000000;
fwrite(&x, 4, 1, fp);

alextram, если при открытии файла вместо режима "w" использовать "wb", то такого эффекта не будет

@Pavel250 · 20.05.2019, 23:09

odip, Спасибо тебе добрый человек!!!! Я уже почти поверил. 10 раз все перепроверил. Прошелся пошагово все четко передает откуда 0x0d. Пишу простенькую реализация сжатия RLE для BMP и последующего вывода микроконтроллером на LCD дисплей. Просто добавлялись биты и вся картинка уезжала.

alextram
		1
	Глючит fwrite (пишет 5 байт вместо 4) 26.03.2011, 11:49. Показов 2406. Ответов 4 Метки нет (Все метки) Среда: C++ Builder 2010. В некий файл пишутся всякие бинарные данные (типы char/int/long) при помощи fwrite. Казалось бы, задача проще некуда. Много раз выполяется команда: fwrite(&x, 4, 1, f); x — типа unsigned long, в ней в момент глюка содержится значение 0xC000000A. Казалось бы, в файле должны оказаться байты: 0x0A 0x00 0x00 0xC0. Но в реальности перед ними откуда-то берётся пятый байт, 0x0D (т. е. 13 — мистика, блин!) До и после этого fwrite стоят fflush(f), так что проблема чётко в данной строке. При этом все остальные данные (в том числе тот же самый 0xC000000A) и до и после глючащей позиции с помощью той же самой команды записываются нормально. Единственное, на что тут могу грешить — где-то раньше до этого была произведена запись в недопустимую область памяти. Но всё равно проявление этого весьма странное. Может, дело в чём-то другом? Бьюсь третий день. Добавлено через 14 часов 31 минуту Переделал вывод под ofstream — работает как часы. Крайне странная история. Вообще, какой способ работы с файлами предпочтительнее в Windows? Ибо выбор большой. __________________ Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь

Evg 21233 / 8246 / 636 Регистрация: 30.03.2009 Сообщений: 22,600 Записей в блоге: 30
	26.03.2011, 12:39	2
	Сообщение от alextram Но в реальности перед ними откуда-то берётся пятый байт, 0x0D (т. е. 13 — мистика, блин!) А ты уверен, что ты в этот файл больше нигде ничего не записывал? Потому что мистики на свете не бывает, а мистика в программировании в 999999 случаях из 1000000 является причиной ошибочно написанного исходника. Ради интереса сделай два одинаковых вызова fwrite подряд. Если окажется, что после этого размер файла равен 10 байтам, то то реально мистика, если 9, то значит где-то в программе есть ещё одно место, которое этот несчастный перевод строки вклеивает 0

@odip 7175 / 3234 / 80 Регистрация: 17.06.2009 Сообщений: 14,164
	26.03.2011, 16:50	3
	Замена кода 0x0A на два кода - 0x0D 0x0A происходит в текстовом режиме работы с файлом Поэтому косяк где-то есть, но у тебя А вообще приводи минимальную рабочую программу, которая демонстрирует глюк 3

@Pavel250 51 / 37 / 14 Регистрация: 05.08.2016 Сообщений: 187
	20.05.2019, 23:09	5
	odip, Спасибо тебе добрый человек!!!! Я уже почти поверил. 10 раз все перепроверил. Прошелся пошагово все четко передает откуда 0x0d. Пишу простенькую реализация сжатия RLE для BMP и последующего вывода микроконтроллером на LCD дисплей. Просто добавлялись биты и вся картинка уезжала. 0

Опции темы